I've got a message queue running, and record ids get added to it in an
However, the message queue is so fast that it can't find the records.
This is because the record hasn't actually been saved back to the
database yet - after_create is called in the transaction.
There's more information on this problem here:
I'm wondering, is there a reason why after_save and after_create are
called inside the transaction?
They are inside the transaction because of the reason mentioned in the
article you linked to:
> I noticed a troubling thing about using after_save to expire
caches, after_save is still within the transaction that save is
automatically wrapped in. I assume this is to protect against an error
during the after_save call, so you can roll back the database to it's
So maybe a patch to add the after_commit API, as used in the article,
would be a good idea.
Or if possible, just use observers.
Ah, sorry, I should have read it closer.
I didn't realize that errors in after_save/after_create would roll
back the save.
Thanks for the suggestion, will do.
As far as I can see observers after_save calls are still in the
Jan De Poorter
Yes, I'm still getting the error.
Here’s a little lib I wrote that implements support for after_commit callbacks: