Support a debug mode and capture unhandled events in debug mode

[ding-an-sich]

It would be useful to debug poorly configured handlers or having the list of all events emitted in an application.

I initially thought about always persisting unhandled events to an ETS table, but I realize that the execute function could be called many times per second so we need to keep the overhead there to a minimum.

So I was thinking of doing it conditionally if the telemetry application is run in debug mode.

For now we could keep things simple and only persist unhandled event names.

Later we could expand the debug mode to do things that are no-nos when running in production.

The downside of this approach is that right now telemetry is so simple that it doesn't need configuration (and that is a good thing) and a debug mode would make it slightly more complex. It also means a possible foot gun for users that could unwittingly set debug mode on production.

[josevalim]

The problem with this is that it would make all handlers today more expensive, because now they need to check if there is a debug mode. The only way to avoid this would be to dynamically compile it with debug mode but I think that it would virtually make it useless. :(

[bryannaegele]

We do publish a failure event when a handler detaches which you can hook into for this.

…

On Sat, Apr 15, 2023, 1:02 PM José Valim ***@***.***> wrote: The problem with this is that it would make *all* handlers today more expensive, because now they need to check if there is a debug mode. The only way to avoid this would be to dynamically compile it with debug mode but I think that it would virtually make it useless. :( — Reply to this email directly, view it on GitHub <#129 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABLXHVOR6QZU2AALWO276TTXBL5GLANCNFSM6AAAAAAW7SVCUE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>