About a week ago I had a problem with after_commit callbacks not being called. It turns out (after diving into the AR source) that they indiscriminately swallow errors from after_commit callbacks. If you're testing a newly-created callback it is difficult to determine whether it's actually been called or merely just raised an error.

I couldn't have figured that out without reading the source- it's not documented. From the developer level that behavior is indistinguishable from magic, and the callback code in AR tries to act like magic as well. It's extremely difficult to follow, let alone understand.

"The after_commit and after_rollback callbacks are guaranteed to be called for all models created, updated, or destroyed within a transaction block. If any exceptions are raised within one of these callbacks, they will be ignored so that they don’t interfere with the other callbacks. As such, if your callback code could raise an exception, you’ll need to rescue it and handle it appropriately within the callback."

http://guides.rubyonrails.org/active_record_validations_call...

"The whole callback chain is wrapped in a transaction. If any before callback method returns exactly false or raises an exception, the execution chain gets halted and a ROLLBACK is issued; after callbacks can only accomplish that by raising an exception."

― http://guides.rubyonrails.org/active_record_validations_call...

I'm not sure what your point is. He was talking about after_commit callbacks. Your quote is about the callbacks during a transaction, not after it.

Huh. Thanks. I looked for a long time and didn't see that. The closest I got was an extremely old lighthouse ticket where Aaron Patterson suggested that they change the behavior to raise errors, but there was no followup.

i didnt want to write new code each time my data-model changed: migrations, model code, new controllers/views. this meant a Resource class, a uniform controller request/response cycle following web-arch/linked-data standards. at this point, would have had to significantly monkeypatch both rails and its attempts at providing a generic Resource class to override its magic (and/or incur the CPU usage for the magic to do what i didnt want). it was a lot simpler to just start with a Rack handler from scratch.

ive been using my web framework for 5+ years for personal and professional projects, and as far as i know there are no other users. Ry Dahl was churning out all sorts of 'concurrent' web-frameworks and servers in Ruby building on EventMachine and so on for years, and im pretty sure i was one of the only people using his code. eventually he scored a hit as node.js when finally rewriting one of the concepts in Javascript

I can second most of this. I haven't needed to dive into the source on Rails 3 at all, except for figuring out why some bit of backwards compatibility wasn't quite working. Considering the project was initially written on version 1.mumble.mumble, I haven't even had to do much of that.