Supporting robust on_commit handlers

[Josh Smeaton]

I recently tracked down an issue in my application where some on_commit handlers didn't execute because one of the previous handlers raised an exception. There appears to be no way to execute on_commit handlers *robustly* as you're able to do with signals [0] using send_robust.

I could sprinkle try/catches around the place, but I'd like to avoid doing so because not all functions that are used as handlers should always swallow exceptions, but could do so when run as on_commit handlers.

Targeting which handlers can be robust or not would be really useful, for example:

def update_search(user):
    # if updating search fails, it's fine, we'll bulk update later anyway
    transaction.on_commit(lambda: search.update(user), robust=True)

def trigger_background_task_one(user):
    # if this task fails, we want to crash
    transaction.on_commit(lambda: mytask.delay(user_id=user.id))

Here if search fails to update it doesn't prevent the background task from being scheduled.

I'm proposing to add a robust kwarg that defaults to False, for backward compatibility, but allows a user to tag specific handlers as such.

[0] ​https://docs.djangoproject.com/en/4.0/topics/signals/#sending-signals