Release v2.7.0

Added

• ParseResult.unrecognized: las unidades que ninguna estrategia
  convirtió en evento, con line y content recortado a 200 caracteres, igual
  que errors. stats.unrecognized seguía siendo solo la cuenta, y con 452
  «sin reconocer» no había forma de saber si era ruido del lambda
  (START/END/REPORT, scheduler de artisan) o un formato por soportar.

Release v2.6.2

Fixed

• Las llamadas al gateway no se emparejaban en el export de Bref. El
  pairKey de Checkout solo se fijaba con aws_request_id, que Bref no mete
  en el JSON (el RequestId va en las líneas START/END del lambda). Sin
  traza, la ida y la vuelta de [GW_LIB] HTTP Req/Res quedaban sueltas y el
  visor las pintaba como dos tarjetas. Ahora la traza cae a transaction_id y
  después a session_id; sin ninguno de los tres sigue sin inventarse un par.

Release v2.6.1

Fixed

• Ids repetidos con hora sin fracción. La semilla del id era la marca de
  tiempo más el mensaje de presentación, que se repite en varias líneas del
  mismo job («State Update (Transaction)»). En el export de Bref, tres líneas
  del mismo segundo compartían id y el visor, que deduplica por id, perdía
  Transaction resolved. La semilla lleva ahora también el contexto.

Release v2.6.0

Added

• Soporte del export de Grafana de un Checkout desplegado con Bref. La
  columna @message trae LEVEL\tmensaje\t{json} en vez del JSON a pelo, sin
  datetime, TENANT_DOMAIN ni aws_request_id, y la hora del CSV viene sin
  fracción. CheckoutGrafanaCsvParser acepta ambos marcadores; el formato
  anterior se sigue leyendo igual. Fixture real recortado en
  test/fixtures/checkout-bref-queue.csv.
• Etiquetas Gateway: Transaction Query (/gateway/query) y Gateway: Transaction Search (/gateway/search), con el motivo cuando no es OK.

Fixed

• Los estados PENDING_* del gateway (PENDING_CONFIRMATION…) se resolvían
  como FAILED; ahora son PENDING y no cuentan como error.
• CheckoutMapper no pasaba el status_code de la respuesta a
  resolveOutcome, así que un 403 del gateway salía como OK.
• El código HTTP de una excepción de Guzzle (`403 Forbidden`) no se leía;
  solo se aceptaba el número a secas.
• Con marcas de tiempo sin fracción, los eventos del mismo segundo se
  ordenaban por id y barajaban «Start Updating» con «Transaction resolved».
  Ahora conservan el orden del fichero.
• El resultado de sesión ignoraba la transacción si el export no traía la
  llamada a /process: una sesión con Transaction resolved: APPROVED salía
  como ABANDONED.

Release v2.5.1

Fixed

• La respuesta del gateway a un pago aprobado se marcaba como rechazo.
  resolveOutcome tomaba como error de negocio cualquier bloque status del
  gateway distinto de OK, y /rest/gateway/process responde APPROVED
  cuando el pago sale bien: el evento llegaba con outcome.isError = true,
  status: "REJECTED" y el mensaje «Approved», y el visor lo pintaba en rojo.

• Transaction resolved no correlacionaba por placetopay_id. Esa línea
  trae el id recién asignado como updated_placetopay_id, con placetopay_id
  todavía en null, y buildCorrelation solo leía el segundo. Justo la línea
  que resuelve el pago se quedaba sin el identificador para filtrar por él.

Changed

• El bloque status del gateway se traduce a resultado, no a error.
  OK, APPROVED y APPROVED_PARTIAL → OK; PENDING y
  PENDING_VALIDATION → PENDING; REJECTED → REJECTED; FAILED y
  cualquier estado desconocido → FAILED. Solo FAILED lleva
  isError: true: un rechazo es la respuesta del proveedor, no un fallo de la
  operación, y no debe contarse entre los errores del lote. code y message
  se conservan en los tres casos para que el visor pueda explicarlo.

Release v2.5.0

Added

• La sesión de checkout dice cómo acabó, no solo si llegó a /process.
  CheckoutSessionMetadata gana transactionStatus (el state del último
  Update transaction trace: Transaction resolved, por orden cronológico: un
  rechazo seguido de un reintento aprobado acaba en APPROVED), outcome
  (APPROVED | REJECTED | PENDING | FAILED | EXPIRED | ABANDONED | UNKNOWN) y
  lastStep, el hito más lejano alcanzado, para decir en qué paso se abandonó.
  hasSuccessfulTransaction se mantiene y equivale a outcome === "APPROVED".
• timings.process, timings.firstEvent y timings.lastEvent, con sus
  derivadas durations.timeToProcess y durations.total. Hasta ahora solo se
  medía cuánto tardaba el usuario en entrar y ver la sesión; faltaba cuánto
  tardó en pagar y cuánto duró la sesión.
• checkout.session.expired fija finalState = "EXPIRED".
• CHECKOUT_FUNNEL_ORDER y el tipo CheckoutSessionOutcome se exportan.
• Fixture checkout-approved-session.csv: export real de Grafana de una sesión
  aprobada de extremo a extremo, con el login del comercio anonimizado.

Fixed

• El retorno al comercio se contaba como 3DS. El hito se marcaba con
  msg.includes("3ds"), y el POST …/return del ReturnController se
  etiqueta «Gateway Return (3DS / Redirection)» aunque no haya habido reto.
  Toda sesión con retorno salía con threeDS: true. Ahora solo cuentan
  /mpi/lookup y el mensaje «Opening 3DS» del propio reto.

Release v2.4.1

Fixed

• Las marcas de tiempo del análisis REST mezclaban zonas horarias. Las
  líneas del SDK (interdin-rest-sdk.log) traen offset propio y se conservaban
  en -05:00, pero las de http.log y laravel.log son naive, así que
  RestNewRelicCsvParser caía al epoch de New Relic y lo renderizaba en UTC con
  toISOString(). En una misma traza convivían 13:35:41-05:00 y
  18:35:45Z, y cualquier visualizador que pintara timestamp tal cual
  mostraba un salto de cinco horas entre el request y su response. El epoch
  (ts) siempre fue correcto; solo el texto estaba desalineado. La misma fuga a
  UTC afectaba a las etiquetas por minuto de groupedBySession.

• El desempate del orden cronológico comparaba textos, no tiempos. Dos
  eventos del mismo milisegundo se ordenaban con localeCompare sobre
  timestamp, que es hora local: con offsets distintos pesaban primero los
  dígitos de la hora y solo después la fracción de microsegundos que se quería
  comparar. Ahora se compara solo esa fracción, como número.

• El respaldo de extractTimestamp para líneas demasiado cortas inventaba la
  hora actual en UTC, reintroduciendo la mezcla de zonas que arregla esta
  versión.

Added

• fromEpochMs(ms, offset?), la contraparte de toEpochMs: rinde un epoch en
  el offset de los logs en vez de en UTC.
• subMillis(timestamp), la fracción por debajo del milisegundo que ts no
  conserva. Ambas exportadas desde el índice.

Release v2.4.0

Fixed

• Las llamadas del SDK se quedaban sin título igual que el Core API. La
  2.3.0 arregló el Core API comparando el mensaje por igualdad, y
  guzzle-logger antepone un prefijo por integración
  (APPLE_PAY-SDK: HTTP Req), así que Apple Pay, Google Pay y Click to Pay
  seguían apareciendo con el mensaje crudo, sin proveedor y con la respuesta
  clasificada como BACKEND_LOG. Ahora cualquier intercambio de Guzzle produce
  APPLE_PAY | POST /paymentservices/startSession y APPLE_PAY | 200 OK, con
  el proveedor tomado del propio prefijo y las categorías HTTP_REQ_OUT /
  HTTP_RES. Sin prefijo sigue siendo CORE_API.

Changed

• El título de estos intercambios usa el identificador del proveedor tal cual
  (CORE_API, no Core API), que es el mismo valor que details.provider.

Release v2.3.0

Fixed

• El Core API se quedaba sin título fuera de /core/tokenize. Sus registros
  llegan con el mensaje HTTP Req / HTTP Res a secas, y solo la tokenización
  tenía un caso propio; el resto de rutas caía al genérico y aparecía en la
  línea de tiempo con ese texto, sin proveedor y con la respuesta clasificada
  como BACKEND_LOG. Ahora cualquier ruta del Core API produce
  Core API | POST /core/ads/search y Core API | 404 Not Found, con
  provider: CORE_API y las categorías HTTP_REQ_OUT / HTTP_RES. La ruta
  sale del mismo sitio que details.endpoint, para que título y endpoint no
  describan la llamada de dos maneras.

Release v2.2.0

Fixed

• Checkout emparejaba solo las llamadas del gateway propio. El rol de un
  registro de guzzle-logger se deducía del texto del mensaje (HTTP Req /
  HTTP Res, o el marcador [GW_LIB]), y cada integración lo redacta a su
  manera: Apple Pay, Google Pay o Click to Pay quedaban como dos eventos
  sueltos aunque compartieran aws_request_id y URL. Ahora el rol sale de la
  forma del contexto —un registro trae request o response, nunca los dos—,
  que es estable entre integraciones. El texto del mensaje se sigue mirando
  primero, así que los formatos que ya emparejaban no cambian.

  Además, la comparación con HTTP Req / HTTP Res exigía igualdad exacta del
  mensaje, y los SDK lo emiten con prefijo de integración
  (APPLE_PAY-SDK: HTTP Req). Ahora basta con que lo contenga. Hay un test con
  un export real de Grafana que lo cubre.