Workers y colas (RabbitMQ)

Idea central: no hay un proyecto de workers aparte. src/index.ts es la API y es cada worker; el rol lo decide la variable de entorno EXECUTION_MODE. En modo worker no clusteriza: un solo proceso.

El dispatch

Prefijo de EXECUTION_MODE	Despacha a
vacío / normal	API HTTP (clusterizada)
sii-worker*	new SIIWorkerManager().start() — src/SIIWorkerConfig.ts
cup-worker*	runWorkFromCupV2() — src/CupWorkerConfigV2.ts
todo el resto	main() en src/WorkerConfigV2.ts — un if/else sobre el string exacto

El archivo a leer antes de tocar cualquier worker

src/WorkerConfigV2.ts. Ahí está el if/else con todos los modos.

Los modos de WorkerConfigV2

publisher · consumer · scrapping-loop · scrapping-worker · scrapping-loop-patients-agreement · scrapping-worker-patients-agreement · descargarOpsDelMes · bulk-ome-validation-worker · read-authorizations · read-all-authorizations · work-all-authorizations · control-account-worker · ome-migration-worker · ome-image-upload-worker · rules-evaluation-worker

Cada modo tiene su npm run dev-* en el package.json, que solo setea la variable de entorno con cross-env.

Las colas

src/config/bbdd/QueueConnection.ts, enum Queues:

Cola	Para qué
PAMI_AUTH2, PAMI_AUTH2_SCRAPING	Autorizaciones
PAMI_ALL_AUTHORIZATIONS_SCRAPPING	Barrido completo de autorizaciones
PAMI_PATIENTS_SCRAPING	Padrón de pacientes
PAMI_PATIENTS_AGREEMENT_SCRAPING, PAMI_PATIENTS_REFRESH_AGREEMENT	Credenciales
PAMI_OMES_SCRAPING, PAMI_PATIENTS_OME_SCRAPING	Estado de OMEs
PAMI_OMES_TRANSMISSION	Transmisión de OMEs
PAMI_OME_IMAGE_UPLOAD	Subida de imágenes de OME
BULK_OME_VALIDATION	Validación masiva de OMEs
pami_billing_op_scrapping	Facturación / OPs
CONTROL_ACCOUNT_ONBOARDING	Cuentas de control
RULES_EVALUATION	Motor de reglas
LOGIN_RESPONSES	Respuestas de login

QueueConnection maneja la reconexión, un canal por cola y un registry de consumerTags para deduplicar consumidores.

El patrón publisher / consumer

El scraping se orquesta por colas: un publisher o un loop llena la cola, y uno o más consumer / worker la consumen y scrapean.

Redis

src/config/bbdd/RedisConnection.ts:

Uso	Keys / detalle
Locks distribuidos	setLock / releaseLock
Caches cortos	Lookups de PAMI (~12 h)
Dedup de scraping	authorization-scrapped-${op}
Metadata de usuario	ACCESSREG-<id>, USERSCOPE-<id>, USERHEALTHCENTERS-<id>
Cápitas del afiliado	PamiCapita* — read-only

Gotchas

Los loops de worker no envuelven todo en try/catch — a propósito

El diseño deja crashear el proceso para que el cluster / Docker lo reinicie. Está comentado en WorkerConfigV2.ts. No lo "arregles" tragando el error en el loop: un scraping que falla en silencio produce datos incompletos sin que nadie se entere.

Un worker que existe en el código pero no está levantado falla en silencio

Un modo nuevo hay que agregarlo al if/else de WorkerConfigV2.ts y dar de alta el container en docker-compose.yml. Ya pasó con el rules-evaluation-worker: el código estaba, el container no, y los hallazgos simplemente no aparecían.

• deploy.sh reinicia los workers sin rolling. Solo la app es rolling.
• La invalidación de cache de Redis importa al cambiar el estado de un episodio o de una OP: si "no se actualiza", mirá las keys de dedup antes que la base.
• Los workers importan services lazy (await import(...)) para bajar el costo de arranque.