Allow setting per-process metadata to unhandled exceptions about appsignal-elixir HOT 3 CLOSED

Hi @1player,

As discussed over support, the way that the AppSignal model of spans and traces works means that it is not possible to do what you describe. Furthermore, the Elixir error backend is something that we would like to deprecate going forward, in favor of framework-specific instrumentations, due to, amongst other reasons, the issues you describe.

In AppSignal, an error belongs to a trace, which is defined by its root span, and that trace is not sent to AppSignal until it is closed. Spans are not something you "inherit" from, or where you set background information for future errors. Spans represent events that take place in your application, within a broader trace that represents a response/request cycle.

If you create a trace on init/1 for your current process, that trace will currently never be closed. The error backend uses its own traces.

If the error backend used the existing init/1 trace, then that error would never be sent, as that trace will never be closed.

If the error backend used the existing init/1 trace and closed it, then the context information that you added would only apply to the first span for which it is reported. Future usages of the error backend would find no active span in that process, as the trace has been closed, and report the information without context.

Unfortunately, what you suggest is not possible to achieve in the way you describe within the AppSignal data model.

from appsignal-elixir.

Sad to see this closed without chance of further discussion.

If traces are incompatible with this request, I do not think it is unthinkable to have a separate API that stores metadata in the process dictionary that can later be attached to the exception, without involving the current design of spans.

As I said in our email conversation, not being able to have some metadata when debugging GenServers make this library less useful than it has a right to be. I hoped we could find a middle ground rather than just shutting down entirely this very valid use-case but alas...

It honestly doesn't feel great having to keep using one of your competitors for error handling because I cannot attach metadata to a process to aid debugging.

from appsignal-elixir.

As you can see, there is a chance of further discussion -- you are engaging on it, comments are not closed. The issue is, however, closed, in the sense that we do not intend to implement this.

I took a look at the implementation for the error backend before closing this, and discussed its implementation with @jeffkreeftmeijer, who initially implemented it, to see if there was a possible quick win that would make your use case better. Long story short, the first issue we encounter is that the error backend is itself run as a separate process, so it is not privy to the context of the process in which the error took place.

There is an attempt to fetch that data anyway from the processes' tracer context (this is why we store it in an ETS instead of merely as process metadata!) and add it to the ongoing trace, but tragically, in practice, the trace is already closed, and therefore lost, by the time that the error backend executes.

We could consider some per-process background metadata that the error backend could fallback to if (as it almost always happens) it fails to attach the error to its original trace. But we'd rather invest our efforts, if possible, in providing a genuinely compelling GenServer instrumentation, rather than on adding opt-in patches to the catch-all, technically-better-than-nothing error reporting system that the error backend provides.

Furthermore, the error backend is an Elixir logger backend, and these are themselves deprecated in Elixir as a whole. Rather than investing our efforts in patching up a system that will be deprecated in the future, we'd rather expand proper instrumentation to more areas of our customers' applications.

from appsignal-elixir.