What is the purpose of job middleware?

[arkaitzgarro]

What is the purpose of job middleware?

[arkaitzgarro]

It was introduced by @cykirsch some time ago, because at that point we were missing transactions for jobs. But now that you mentioned it, it might be the case that we don't need it anymore. @cykirsch thoughts? Can it be removed, or are we missing something?

[cykirsch]

It's only to record a span closer to the actual processing of the job, really the only benefit (if any) is that closeness. I agree it could be pulled out, and now would be the time while bumping the major version.

If someone wants that behavior, it's easily reproducible manually via the facade.

[arkaitzgarro]

I see it now. There's an extra span in the transaction but only if the jobs are synchronous of course. It might be worth keeping it then, it shows at which point the job was executed in the context of the transaction.

[dstepe]

At a minimum, the documentation should be updated to make the use case clear.

However, I'm running into trouble reproducing your results in a reference app I've built for functional testing. When I use the dispatchNow() method of a job, the job middleware is not called at all. The middleware is only used when run with the queue worker. How are you creating the sync job? I'm using Laravel 7.28.x at the moment.

[cykirsch]

I’m just reading this on my phone so I didn’t look any closer to give this answer, just tossing out a quick suggestion. Try still calling dispatch() but change your driver to ‘sync’. To me, that’s what it sounded like he was doing.

…

On Wed, Oct 14, 2020 at 07:53 Dirk Tepe ***@***.***> wrote: At a minimum, the documentation should be updated to make the use case clear. However, I'm running into trouble reproducing your results in a reference app I've built for functional testing. When I use the dispatchNow() method of a job, the job middleware is not called at all. The middleware is only used when run with the queue worker. How are you creating the sync job? I'm using Laravel 7.28.x at the moment. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#90 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACDPP47ZPBBWUQL64Y2XCXLSKWNL3ANCNFSM4SOSTR7A> .

[dstepe]

That makes sense, but is a very different use case. I know I have one real-world situation in which we make a runtime decision between dispatch() and dispatchNow() based on a condition. But this helps explain the behavior. I'll confirm it shortly. If this is the case, we can update the docs and provide some suggestions on how to handle these cases.

[dstepe]

A quick test supports this hypothesis. The middleware is called if the queue connection is sync, which implies the middleware is always called for jobs created with dispatch(). The middleware is not called for jobs created with dispatchNow().

As an application author, I'm not sure I would expect that difference in behavior related to APM. We can document it, but we can't provide a solution. The only way to get APM data for a job created with dispatchNow() would be to use the facade and do it yourself.

Suggestions on how to proceed?

[cykirsch]

Any other span within the job is still recorded, but it is just missing the overarching span showing how long the job itself takes.

…

On Wed, Oct 14, 2020 at 09:23 Dirk Tepe ***@***.***> wrote: A quick test supports this hypothesis. The middleware is called if the queue connection is sync, which implies the middleware is always called for jobs created with dispatch(). The middleware is not called for jobs created with dispatchNow(). As an application author, I'm not sure I would expect that difference in behavior related to APM. We can document it, but we can't provide a solution. The only way to get APM data for a job created with dispatchNow() would be to use the facade and do it yourself. Suggestions on how to proceed? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#90 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACDPP4ZWBDEGQAIACPAELELSKWX45ANCNFSM4SOSTR7A> .

[dstepe]

Understood. I'm leaning toward simply updating the documentation state that jobs created with dispatchNow() will not have the middleware run, though any explicitly created measures with the job will still be recorded. Then app developers can decide how they want to proceed.