george.calle
5a2e149825
- index.ts: guard tickRunning; un tick largo ya no se solapa con el siguiente de node-cron (causaba -2035 en @EVN1 y -1116 cruzados por requests concurrentes sobre la misma sesion de Service Layer). - process-tick.ts: un evento con error ya no corta el tick; progreso cada 100 eventos; envios en lotes de MAX_EVENTS_PER_BATCH (default 30) para no superar el tamano de body del receptor (HTTP 413). - evn1-repository.ts: findExisting falla si el GET falla, en vez de tratarlo como "no existe" y crear un duplicado. - service-layer-client.ts: errores incluyen metodo, ruta y body. - logger.ts: no poder escribir el archivo de log no tumba el proceso. - CLAUDE.md: notas operativas y mejoras pendientes.
43 lines
2.1 KiB
Markdown
43 lines
2.1 KiB
Markdown
# CLAUDE.md
|
||
|
||
Notas operativas para trabajar en este repo. El diseño completo está en
|
||
`docs/DISENO.md`.
|
||
|
||
## Entorno de este servidor
|
||
|
||
- El `.env` apunta a **producción** (`SBOPRDLIBROS`, SAP B1 sobre HANA).
|
||
Cualquier `npm run run-once` / `npm start` escribe en `@OEVN`/`@EVN1` y
|
||
envía webhooks reales a la suscripción activa en `@OEVC`.
|
||
- El dispatcher corre como servicio Windows NSSM `sap-legacy-webhook`
|
||
(cuenta LocalSystem). **Detener el servicio antes de correrlo a mano**
|
||
(`Stop-Service sap-legacy-webhook`) y volver a iniciarlo después: dos
|
||
procesos en paralelo comparten eventos y duplican entregas.
|
||
- Los logs diarios (`logs/dispatcher-YYYY-MM-DD.log`) los crea SYSTEM; un
|
||
usuario normal no puede escribirlos. El logger cae a solo-consola en ese
|
||
caso (no es un error).
|
||
|
||
## Lecciones aprendidas (2026-10-20)
|
||
|
||
- **Ticks solapados**: con backlog grande un tick dura más que
|
||
`POLL_INTERVAL_SECONDS`, y node-cron lanzaba otro en paralelo sobre la
|
||
misma sesión de Service Layer → `-2035 already exists` en `@EVN1` y
|
||
`-1116` (a veces "Unknown error", a veces violación de `KEVN1_NAME` con
|
||
la clave de *otro* request). Corregido con el guard `tickRunning` en
|
||
`src/index.ts`. Si reaparecen `-1116` cruzados, sospechar concurrencia
|
||
sobre la misma sesión antes que datos.
|
||
- **Tamaño de lote**: el receptor rechaza bodies grandes (HTTP 413). Los
|
||
envíos se parten en lotes de `MAX_EVENTS_PER_BATCH` (30 por defecto).
|
||
|
||
## Mejoras pendientes
|
||
|
||
- **Lock de instancia única**: archivo de bloqueo (ej. `logs/dispatcher.lock`
|
||
con el PID) para que una segunda instancia —servicio o ejecución manual—
|
||
se cierre al arrancar. Hoy solo lo evita la regla operativa de arriba.
|
||
- **Paralelizar llamadas al Service Layer** dentro de un lote (GET de
|
||
eventos / PATCH de `@EVN1` de a 5–10) para vaciar backlogs grandes más
|
||
rápido. Cuidado: misma sesión de SL — validar que tolera concurrencia o
|
||
usar sesiones separadas (ver lección de ticks solapados).
|
||
- **Causa del `-1116` aislado**: tras el fix de solapamiento no se volvió a
|
||
ver; si aparece con un solo tick en curso, el log ahora indica método,
|
||
ruta y body exactos.
|