import { HttpContextToken, HttpInterceptorFn } from '@angular/common/http';
/**
 * Marca un request cuyo 404 es un ESTADO ESPERADO del dominio, no un error —
 * ej. `GET /v1/game-profile/me` cuando el usuario todavía no creó su perfil
 * de juego. Mismo criterio que el 401 de abajo (ruido normal del flujo, no
 * un bug): se loguea a consola como `info`, nunca a Analytics como error.
 *
 * Uso en el caller: `this.http.get(url, { context: new HttpContext().set(EXPECTED_NOT_FOUND, true) })`.
 *
 * No aplica a TODO 404 — solo a los que el propio caller sabe que son un
 * "todavía no existe" legítimo. Un 404 no marcado sigue siendo error real
 * (URL rota, recurso que debería existir) y se loguea como tal.
 */
export declare const EXPECTED_NOT_FOUND: HttpContextToken<boolean>;
/**
 * Interceptor HTTP de observabilidad (Capa 1 del estándar de manejo de errores).
 *
 * Para CADA respuesta HTTP con error:
 * 0. Si es un GET (idempotente) que falló con 502/503/504, reintenta hasta 2
 *    veces con un backoff corto (400ms/800ms) ANTES de pasar al resto del
 *    pipeline — el caso típico es un cold-start de Lambda en dev: 3-4
 *    requests en paralelo al bootstrap (auth/profile + runs + org/{id})
 *    pegan contra lambdas frías al mismo tiempo, todas 504, y ~2s después ya
 *    están tibias y funcionan. Detectado en Merotz dev 2026-08-17. Nunca
 *    reintenta POST/PUT/DELETE/PATCH (no son idempotentes) ni 4xx (error de
 *    negocio, reintentar no lo arregla).
 * 1. Si sigue fallando tras los reintentos: normaliza el error con `interpretError`.
 * 2. Loguea un evento estructurado a consola con el prefijo `[HTTP]`.
 * 3. Reporta el error a Firebase Analytics (`source: 'http'`), si hay analytics.
 *
 * **NO traga el error** — lo re-lanza tal cual. Las páginas y servicios siguen
 * recibiendo el error en su `catch` / `catchError` y deciden la UX (eso es
 * Capa 3: `ValtechErrorService`).
 *
 * `AnalyticsService` se inyecta `@Optional()` — apps sin Firebase Analytics
 * igual obtienen el log estructurado a consola.
 *
 * Decisión sobre 401: **se saltea** del tracking de Analytics. Un 401 es el
 * disparador normal del flujo de refresh de token del `authInterceptor`; el
 * token se renueva y la request se reintenta de forma transparente. Trackear
 * cada 401 inundaría Analytics de ruido (cada sesión genera varios al expirar
 * el access token). El 401 SÍ se loguea a consola (nivel `info`, no `error`)
 * para no perder la traza en debugging local, pero no se reporta como error.
 *
 * Se registra vía {@link provideValtechErrorHandling}.
 */
export declare const errorLoggingInterceptor: HttpInterceptorFn;