I’m not proposing catching errors in query calls at this point in time.
Could this off-chain mechanism be implemented by a non-DFINITY developer team, or do you have something in mind at the protocol level?
If we’re having this discussion, it might be even better to build some sort of DLQ tooling at the protocol level. I’ve had some thoughts about what a general purpose DLQ would look like on at a higher software level, but it seems like something like that could utilize the canister_on_error() type of failures and send these raw error metadata to an DLQ/logger type of canister. You could then imagine the user being able to redrive API calls and events that had failed through inter-canister calls instead of ingress messages.
I’m perfectly fine with starting small and building from that. Start with one or two hooks, and see what the residual effects on the canister message queues, etc. look like before adding more.
In fact, if we were ordering these “hook” type of features in terms of ease of implementation and immediate developer impact, I really think that Proposal: Configurable Wasm Heap Limit should come first since it’s synchronous, followed by canister_on_low_memory() and canister_on_low_cycles().
I agree canister_on_error() and canister_post_init() could use some more time to marinate!