default_watch_categories se estableció desde el valor predeterminado (que no es nada, si no recuerdo mal) a una sola categoría, probablemente por primera vez.
Esto desencadenó un volumen masivo de correos electrónicos; durante un período de 3 días, se procesaron casi 400 000 reintentos de correo electrónico, y más del 09 % fallaron. Muy temprano, esto activó la limitación de velocidad del lado de los proveedores de SMTP (¡lo que evitó una factura de correo electrónico masiva e involuntaria!).
La configuración de default_watch_categories se restableció, ya que se estableció inadvertidamente.
Sin embargo, Sidekiq todavía mostraba un gran volumen de reintentos de correo electrónico, porque las limitaciones de velocidad de los proveedores de SMTP todavía estaban en vigor, seguía intentando y fallando.
Al inspeccionar más de cerca, parecía que ahora era solo una publicación la que desencadenaba continuamente el mismo correo electrónico una y otra vez, en cientos y luego miles de reintentos, a pesar de que default_watch_categories se había restablecido a su valor predeterminado. ¿Qué estaba pasando?
Una vez que esa publicación y otras debajo de ella se dividieron en su propio tema “nuevo” por razones normales de moderación, el desencadenante de correo electrónico y los reintentos se detuvieron por completo como un beneficio adicional. No más reintentos.
¡Gracias a los cielos por la limitación de velocidad de los proveedores de SMTP!
Como una visión adicional: esto solo se detectó cuando falló, debido a los limitadores de los proveedores de smtp. Quizás una lectura más clara en el panel de la actividad de envío de correos electrónicos del día durante los últimos 7 días, 24 horas y hora, con alertas para cualquier pico, podría ser bienvenida.
Este tipo de cosas podrían causarte muchos problemas financieros.
¡Esto podría haber consumido nuestros costos de alojamiento de un año en un par de días si el proveedor no hubiera activado los límites de velocidad!
