Error handling and rollbacks in nodeapi and other hooks

The current design of nodeapi (or all hooks for that matter) is such that on an insert, first the node is created, then the hook_insert of the specific module is called and finally all the nodeapi hooks are called. Now, at present, hook_insert and hook_nodeapi implementations don't have a return value. This creates a problem in case a fatal error occurs. There is no way to immediately rollback the change or let node.module know that something went wrong. I ran into this during the development of http://www.ourmedia.org

When a user is uploading a video, there are several things that need to happen. The file needs to get uploaded, the metadata needs to get captured and validated and finally a seperate module (IA.module) needs to ftp the file to the Internet Archive. We do most of this weight lifting in hook_insert of the media modules. IA module does its work via nodeapi. Now, even if one of the steps fails - like the ftp failed, or metadata save failed (I agree this is very unlikely unless our database server is choked) the node gets created anyway. And worse, the user gets no indication of the same. So we end up with many 'zombie' nodes.

I discussed this briefly with Moshe as well. I have been thinking if it makes sense to have hook_insert and certain other hooks to return error codes. For example, if hook_insert fails, it could return a failure code. Similarly if one of the nodeapi calls failed, then subsequent calls can be halted. Or we could even rollback the created node. To take it to an extreme, there could be a hook_rollback as well which modules could implement. Then if a fatal error occurs, for each module whose hook_nodeapi was executed, the hook_rollback could also be called. This is similar to the standard C++ application programming paradigm of checking error codes on each call (if (HRESULT)...) and bailing out in case of an error.

I guess this is not a big issue for 95% of the cases because content management largely involves database inserts which rarely (but not never) fail. But situations can arise (like the case I described above), where a more robust error handling and rollback architecture could make drupal stand out.

Comments?