Tareas pendientes

Trabajo identificado pero no construido — a diferencia de lo que documenta cada entrada, que describe comportamiento que ya existe. Cada punto lleva el razonamiento por el que se planteó, para no tener que reconstruirlo al retomarlo.

Anotado el 2026-09-14. Los dos puntos sobre los CI de notificaciones —paths-ignorey refrescar el checkout de la api antes de construir el worker— se aplicaron ese mismo día y salen de la lista. El de quitar el down del deploy de petid-api también está aplicado: su CI construye, migra y recrea solo api con --no-deps.

1 · Documentar el .env por repo en la entrada del contrato

Lo que está duplicado a propósito explica la dirección api → worker del schema y del contrato de cola, pero no dice nada de la configuración, y ahí hay un acoplamiento que sorprende:

Cada servicio lee su .env con env_file, y ese fichero solo lo escribe el workflow de su propio repo. Cuando el deploy de la api reconstruye el worker, no toca el .env del worker. Normalmente da igual, porque env_file se lee al arrancar el contenedor y no se hornea en la imagen — pero si añades una variable nueva al worker, hay que pushear el repo del worker para que su workflow la escriba. Desplegar solo la api lo reconstruiría con la variable ausente, y eso falla en ejecución, no al construir.

2 · El limiter va atado a la concurrencia del worker

Los processors del worker corren con concurrencia 1, que es el valor por defecto de BullMQ: nadie lo configuró. Hoy eso no limita nada —la ingestión está capada mucho más abajo— pero es el único freno del lado del worker contra el límite de peticiones del proveedor.

Por eso esto no es «implementar un rate-limit por canal», que sería trabajo sin beneficio actual y con números inventados. Es una condición:

El día que se suba la concurrency de una cola, el limiter de esa cola se pone en el mismo commit, con el límite real del plan de proveedor que haya entonces.

Subirla para desatascar una cola sin tocar el limiter es quitar el freno sin saberlo. El valor del plan por defecto de Resend anda por las 2 peticiones/segundo, pero hay que confirmarlo contra el plan contratado antes de fijar ningún número.

3 · Validar el tamaño del payload de push

FCM rechaza los mensajes que pasan de unos 4 KB, y ahora mismo nada lo comprueba: no hay ninguna validación de longitud ni de forma sobre eltitle, el body ni el data ya renderizados.

El fallo llega del proveedor, así que el push se marca FAILED con el error de FCM enmeta — es ruidoso, no silencioso, y por eso está al final de la lista. Pero se descubre en entrega y por destinatario, cuando validarlo al guardar la plantilla lo cazaría una vez y para siempre, igual que ya hace assertChannelPayload con el canal.

Cuidado con dónde: el tamaño real depende de las variables ya interpoladas, así que una plantilla corta puede pasarse al renderizar. Validar la plantilla acota el problema pero no lo cierra del todo.