Using System.stacktrace() within exq middleware behaviour implementation

Before Elixir 1.7 we were happy to send errors to appsignal when exq job failed to complete.
We have implemented a middleware behaviour to achieve that.

defmodule Exq.Middleware.AppSignal do
  @moduledoc false

  @behaviour Exq.Middleware.Behaviour

  alias Exq.Middleware.Pipeline
  import Pipeline

  def before_work(pipeline) do
    transaction =
      Appsignal.Transaction.generate_id()
      |> Appsignal.Transaction.start(:background_job)
      |> Appsignal.Transaction.set_action("Exq/#{pipeline.assigns.worker_module}")
      |> Appsignal.Transaction.set_sample_data(
        "environment",
        %{job_id: pipeline.assigns.job.jid}
      )

    assign(pipeline, :appsignal_transaction, transaction)
  end

  def after_processed_work(pipeline) do
    transaction = pipeline.assigns.appsignal_transaction
    Appsignal.Transaction.finish(transaction)
    Appsignal.Transaction.complete(transaction)

    pipeline
  end

  def after_failed_work(pipeline) do
    transaction = pipeline.assigns.appsignal_transaction

    _ =
      Appsignal.Transaction.set_error(
        transaction,
        "Exq job failed with exception",
        pipeline.assigns.error_message,
        System.stacktrace()   # <---- DEPRECATED!
      )

    Appsignal.Transaction.finish(transaction)
    Appsignal.Transaction.complete(transaction)

    pipeline
  end
end

In Elixir 1.7.2 System.stacktrace() is deprecated, so we are wondering what would be the best way to report errors to appsignal from our middleware.

We can pass stacktrace as [ ]. That is not ideal, as it would be great to have stacktrace.

As compilation warning suggests, use __STACKTRACE__ in try/rescue block and once we have stacktrace pass it to after_failed_work callback as second parameter? But that would mean that we have to suggest to change Exq.Middleware.Behaviour definition to allow optional stacktrace argument.

If you have an idea of how we can solve this, don’t hesitate to share and discuss.

2 Likes

Ugly and slow, but you could maybe ‘make’ your own stacktrace? by just raising and catching your own error? Though getting a stacktrace in the old versions was not fast either so eh. ^.^;

Yeah. That’s an interesting idea. I’ll keep it in mind. Also, I will dive into exq library to see if stack trace can be passed to the after_processed_work.

We have the same issue, that is, using System.stacktrace/0 without an exception and therefore no rescue/catch.

We have some code where we handle error tuples by collecting information, which includes the stacktrace, and send the data to a monitoring service.

def set_error(transaction, name, message, reason) do backtrace = ([reason] ++ 
  System.stacktrace()) |&gt; Enum.map(&amp;inspect/1) 
  Appsignal.Transaction.set_error(transaction, name, message, backtrace)
end

I’ve considered creating our own fake exception but that changes the stacktrace.