Point d'alerte sur l'usage des handlers de telemetry pour envoi d'email

[thbar]

En travaillant sur une implémentation pour :

• Tracer idle_time et queue_time (pool Ecto) dans AppSignal #3443

Je me suis rendu compte qu'on avait peut-être un souci potentiel ici:

transport-site/apps/transport/lib/jobs/oban_logger.ex

Line 38 in 2ccb1ed

def setup, do: :telemetry.attach("oban-logger", [:oban, :job, :exception], &handle_event/4, nil)

On utilise un handler de télémétrie pour notifier des échecs de certains jobs, par email.

Or, comme cela m'est revenu pendant mon implémentation:

• https://elixirforum.com/t/how-to-deal-with-detached-telemetry-handlers-caused-by-errors/56069/2

Handler code runs inline wherever events are emitted – in the same process emitting the events – which is the reason for those tight constraints around failure. The upside of that approach is that telemetry doesn’t involve message passing, which can be a problem with large enough data as context and/or volume of events.

Ce qui m'a d'ailleurs amené à ouvrir un ticket ici sur le même type de sujet:

• Are calls to add_distribution_value synchronous or asynchronous? Can they raise errors? appsignal/appsignal-elixir#887

L'impact est multiple:

• l'appel va être synchrone dans l'event handler. Selon comment c'est implémenté, cela pourrait
• mais surtout, j'ai la sensation qu'une erreur levée dans le code pourrait se traduire par un détachement du handler, et donc un arrêt des notifications (à vérifier)

À creuser donc!