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
Yes, it happens, and it's difficult to catch those quirky mistakes in dev.
That's why I build a staging local server out of an old machine that I don't use anymore that's only on my home/office network that matches the exact same stack I use in production.
I deploy to the staging server first, test the hell out of it, and then when I'm confident, and only then, push to production.
Nice! I do a conceptually similar thing, but with Docker.
One thing that annoys me with my Docker approach and these modern Macs, is that I'm still running a different CPU architecture than in production 😄️
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!
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.
