Improve terminating callbacks visibility

[stayallive]

Code using something like dispatch(function () { ... })->afterResponse() did not show up in the performance traces. Even though the user wouldn't notice the impact on the response time I feel like we should still provide insight in it.

In another PR I'm working on I'll try to give better context on where the request actually ended (response sent) and where the terminating timeframe begins etc., coming soon ™️

Before:

After (notice the "new" queue.process span):

[diogogomeswww]

On our case we don't want to include the "afterResponse" in the performance trace.
Because of that we are force to downgrade this package version.

Can we make this configurable?

I'm happy to do a PR.

[stayallive]

@diogogomeswww can you eloborate why not? What is the downside for you?

[diogogomeswww]

We track the performance of some endpoints, and we want to track the performance through the users perspective.
Hence we are sending some "work" to be dispatched after the response.

Does that make sense?

[cleptric]

Having a config to opt-out of this seems reasonable to me. Out of curiosity, do you exclusively use blade templates or other SSR technologies? I would assume to measure performance from a user-perspective rather from the FE side.

[diogogomeswww]

We have API Endpoints that need to be fast.
And all work on those API Endpoints that is not needed to return the response to the user, is done using the dispatchAfterResponse.

Please give me a thumbs up and I will do the PR to add a config variable to include or exclude the dispatchAfterResponse in the performance trace.

[cleptric]

We'll take care of this, no worries 🙂