Here's yet another example of how I got burned when my local dev environment didn't match my prod environment. Sync queues work differently than other queue types.
masteringlaravel.io/daily/2024-08-06-sync-queue-works-differently-than-async
Actually, the tip should be not to serialize models in asynchronous queues.
Takes up to much memory with Redis.
Yeah I agree with that, but I am still curious of what the code looked like. In some cases I can see why passing a model to a job can make sense
Serialization isn't 100% accurate here since Laravel only stores Eloquent model IDs and re-hydrates from the database. But the problem is the same: you lose access to in-memory change state.
It does do that? I remember it differently. It was i believe Mohammed Said (Mr. Queues) who suggested to only pass the ID of the model and never serialize the model in a job.
You'd rather have job middleware or some method in your job that checks, if you still need to handle the job
It‘s a question of what you need in the job. If it‘s okay for the job to work with a fresh model, only pass the ID and load the model from the DB (what is the case in 99%). If you really need the object, you have to serialize the model and be aware of possible impacts (complex object serialization, stale model data in async jobs, data exposure, …)
Yes, Laravel handles it for you with the `SerializesModels` trait. Very handy!
look at that, and i naively thought serialization means transforming the object to a string representation and vice versa.
TIL! Thank you for enlighten me
The test as originally written was passing because the queue was running synchronously.
The solution involved capturing the change state as a separate job param and passing it along with the model. This approach no longer relied on the change state being in memory when the job was processed.
