Le puse un chivato a mis propios errores

Varias publicaciones se quedaron sin subir, días distintos, marcas distintas. No hubo ni una sola alerta. El propio código se lo tragaba en silencio con un catch vacío — el tipo de línea que escribes deprisa un día y te olvidas de que existe, hasta que te cuesta caro.

💡 En resumen, para quien tenga prisa

Encontré un catch (err) {} completamente vacío justo en la función que programa cada publicación de Instagram, Facebook y LinkedIn. Si esa llamada fallaba —por lo que fuera—, la publicación se quedaba en cola para siempre, sin ningún error registrado, sin ningún aviso. Lo arreglé para que el fallo se registre de verdad, y además monté un aviso por WhatsApp que me llega al instante si vuelve a pasar. Ya no depende de que alguien lo note por casualidad.

📉 El síntoma

Iba a comprobar algo que me habían pedido de pasada — "mira si hoy había posts que no se han subido a Forvia" — y al mirar la cola de publicaciones programadas me encontré con más de una. No una, varias. De marcas distintas. De días distintos, algunas de hacía más de 24 horas.

Ninguna tenía nada raro en la base de datos. Ni un mensaje de error. Nada.

🐛 Lo que no cuadraba

Publicaciones "en cola" desde hacía días, con su hora de publicación ya muy pasada, y ningún campo de error relleno. Si algo hubiera fallado de verdad, tendría que haber quedado registrado en algún sitio. No había nada.

🕵️ Bajar un nivel

Cada publicación programada dispara, por debajo, un proceso que se encarga de publicarla a su hora — y ese proceso, si todo va bien, queda "vivo" esperando el momento justo. Fui a comprobar si ese proceso existía de verdad para una de las publicaciones atascadas.

No existía. Nunca se había creado.

Eso ya apuntaba a otro sitio: no era un fallo publicando, era un fallo programando — algo que pasaba mucho antes, en el momento de crear la publicación, no en el momento de subirla.

🔎 El catch vacío

Fui directo a la función que se encarga de arrancar ese proceso. Y ahí estaba:

try {
  await client.workflow.start(...)
} catch (err) {}

Tres caracteres — {} — capaces de tragarse cualquier fallo real sin dejar ni rastro. Si esa llamada fallaba por lo que fuera (una conexión inestable, un problema puntual del sistema que coordina las publicaciones), el error simplemente desaparecía. La publicación se quedaba en su sitio, en apariencia normal, esperando una hora que nunca iba a llegar.

🐛 Por qué es peor de lo que parece

No es solo que faltara un aviso — es que no había ninguna forma de saber que algo había fallado sin ponerse a comparar manualmente cada publicación programada contra lo que de verdad estaba corriendo. El sistema, desde fuera, parecía sano. Por dentro, llevaba días perdiendo publicaciones sin decir nada.

🔧 El arreglo con red de seguridad de verdad

Lo primero fue lo obvio: que ese catch deje de estar vacío. Ahora registra el error y lo manda a nuestro sistema de seguimiento de errores.

Pero solo con eso, el aviso sigue dependiendo de que alguien entre a mirar. Así que fui un paso más allá: si esa llamada falla, me llega un WhatsApp al momento, con el post afectado y el motivo. Lo mismo para cualquier publicación que llegue a fallar de verdad al intentar subirse (sesión caducada, contenido rechazado, lo que sea) — antes ese tipo de fallo se veía, como mucho, si entrabas a mirar el panel.

Y por si algo se me escapa incluso con esto: añadí una revisión automática cada 15 minutos que busca publicaciones atascadas sin proceso activo detrás y las relanza sola, sin que tenga que enterarme yo primero.

⚠️ Lo que no quise hacer

No toqué la forma en que el sistema se conecta por dentro para intentar evitar el fallo original — eso habría significado cambiar cómo funciona una pieza que usa todo el proyecto, sin poder probarlo con calma antes. Prefiero enterarme al instante de cada fallo que arriesgarme a una reforma a ciegas en producción.

📋 Antes / después

🎓 La moraleja

Un catch (err) {} vacío no es una gestión de errores — es la ausencia de una, disfrazada de código que compila sin quejarse. Se escribe en dos segundos, generalmente con la mejor intención ("esto no debería fallar nunca"), y es exactamente el tipo de línea que nadie vuelve a mirar hasta que ya ha hecho daño durante semanas.

Lo que de verdad cambió las cosas no fue solo arreglar ese error puntual, sino dejar de confiar en que "si no veo ningún error, es que no lo hay". Ahora, si algo falla, me entero antes que el cliente. Esa es la única versión de esto que de verdad sirve.