Errors thrown when message is received by a subscriber

[meliksetyanruben]

I have a simple setup of SQS consumer bound to a specific topic. Although the consumer successfully receives and processes messages from the queue, the following errors are being reported in the log file:

[2022-11-27 14:23:34] development.ERROR: Cannot access offset of type string on string  
[2022-11-27 14:23:34] development.ERROR: method_exists(): Argument #1 ($object_or_class) must be of type object|string, null given

What I find interesting is that logging of this two messages happen just before the start of execution of handle method and one more time after the execution is finished, e.g.:

[2022-11-27 14:23:34] development.ERROR: Cannot access offset of type string on string  
[2022-11-27 14:23:34] development.ERROR: method_exists(): Argument #1 ($object_or_class) must be of type object|string, null given
[2022-11-27 14:23:34] development.INFO: Started execution...
[2022-11-27 14:23:35] development.INFO: Finished execution...
[2022-11-27 14:23:35] development.ERROR: Cannot access offset of type string on string  
[2022-11-27 14:23:35] development.ERROR: method_exists(): Argument #1 ($object_or_class) must be of type object|string, null given

I am unable to trace the issue down and will be grateful for any kind of assistance.

amranidev/micro-bus version: v0.3.3 laravel/framework version: v8.83.26

[amranidev]

Hi @meliksetyanruben, Thanks for opening this issue, I will make sure this issue is resolved for you. First, we want to know if you generated the subscriber class using the underlying subscriber artisan command or by creating it from scratch?

What kind of SQS you configured, FIFO or Standard?

Also if you can provide more details that might help us help resolve this issue. (How do you run queue, supervisor, etc...)

[meliksetyanruben]

Hi @amranidev, thanks for quick response.

The subscriber was generated by the artisan command. We are using a standard SQS queue. As for the queue consumption, in production the job is run using supervisor, however the issue persists also when running locally with php artisan queue:work subscriber

I'm not sure if this might help but SNS subscription for the queue has filter policy attached. The message is routed to a specific queue based on a certain value and each queue is consumed by a single application instance.

[amranidev]

@meliksetyanruben I see, do you have any resolvable IOC container kind of things inside the subscriber class? something like app(Something::class).

Or methods that implements the Laravel dependencies injection container? e.g function(Something $object).

Or does the handle() method has a resolvable parameter handle(Something $object)?

[meliksetyanruben]

@amranidev The subscriber implementation is very simple. No dependencies are resolved from the container. The payload is decoded and a simple database call is made directly from model (no repos or services are injected).

[amranidev]

@meliksetyanruben I see, thanks, I will investigate on my end and let you know.

[amranidev]

@meliksetyanruben

This issue is very weird, I couldn't reproduce it at all, however, I find exactly where the error is happening, at least this one

[2022-11-27 14:23:34] development.ERROR: method_exists(): Argument #1 ($object_or_class) must be of type object|string, null given

The subscriber class is implementing a trait called JobHandler which verify the existence of the handle method method_exists As the error indicates, the first param must be a type of object or string.

        if (!method_exists($this, 'handle')) {
            throw new \Exception(__CLASS__.'@handle does not exists!');
        }

As a conclusion, we could say that $this is null. (Which doesn't make any sense)

One important indicator that might be the cause is Laravel container is not working smoothly when it comes to executing the jobs with the queues, sometimes it gives wrong results, that's why I asked you those kind of questions in the beginning.

The subscriber driver is built on top of the Laravel queue system, extending the SQS jobs functionalities. The subscriber job is being resolved by the Laravel Job class, which again a built-in kit and it's using service container to resolve Jobs.

This is my hypothesis, but of course it need to be validated.

Does your all your microservices affected by this issue or just some of them? Also does your jobs get completed when after execution?

[meliksetyanruben]

@amranidev

Thank you for detailed explanation. The issue indeed is very strange.

We have only one more microservice that uses the library, however it uses both subscriber and publisher functionality. Another difference is that subscriber driver is set as the default in this microservice and it is run using php artisan queue:work whereas in the first microservice (where error is happening) we run php artisan queue:work subscriber since there are other queues utilized besides S.QS

[amranidev]

@meliksetyanruben - I've published a new release for the package, I still couldn't repreduce your issue, but that might be caused by serialization at some point, I've removed that feature.

the new version is v0.3.4 if you want to try it out.

Thanks

[pleaz]

conflict with this package https://github.com/imTigger/laravel-job-status

[amranidev]

Hi @pleaz, can you please provide more details how it's conflicting with micro-bus?

[pleaz]

Hi @amranidev, everything same as described before same errors, if you just install the package 'laravel-job-status', you will reproduce these errors, maybe that's more problem in 'laravel-job-status', I just wanted to mention the reason of that problem

[amranidev]

Thanks @pleaz - I've installed the /laravel-job-status and I was able to reproduce the issue. seems an issue in their end.

[amranidev]

@meliksetyanruben - I've created a PR for laravel-job-status, https://github.com/imTigger/laravel-job-status/pull/78, if the maintaner decided to merge it and bump a release, then you should upgrade the laravel-job-status. if the PR didn't got merged then you will have to remove the https://github.com/imTigger/laravel-job-status from your project 🤷‍♂