clockworklabs
`OnUnhandledReducerError` in client SDKs
Name not yet decided. Semantics basically locked in by BitCraft needs. Specifically:
When receiving a TransactionUpdate for a known reducer with status Failed or OutOfEnergy, check if there are any callbacks registered on that reducer. If none are registered, invoke the OnUnhandledReducerError with a ReducerEventContext containing the failed reducer and with an Error/Exception object that contains the error message.
Callbacks are of the type FnMut(&module_bindings::ReducerEventContext, sdk::Error).
For the OutOfEnergy case, the passed Error should be distinguishable as meaning out of energy.
Callbacks are registered and removed directly on the DbContext. In Rust, this means the trait DbContext has methods on_unhandled_reducer_error(&self, callback) -> OnUnhandledReducerErrorCallbackId and remove_on_unhandled_reducer_error(&self, callback_id: OnUnhandledReducerErrorCallbackId).
This is high priority in C#, as BitCraft needs this functionality. It is significantly lower priority in Rust and TypeScript.
Do you know if there's a time-sensitive need for this, besides "in time for the next bitcraft milestone"?
Well, it needs to be done with enough lead time for the BitCraft team to use it in their code and properly test their code.
On the C# side, it seems that the state for this will need to be held inside RemoteReducers rather than DbConnection. However, as phoebe pointed out to me, it's probably still better if the registration stuff goes on DbConnection so that there is no confusion when there is a reducer named unhandled_reducer_error. I think that basically makes sense -- DbConnection can call some sort of internal method on RemoteReducers to make this happen. I suspect something similar will hold in Rust and Typescript.
The C# stuff is in review. I know we like to keep parity between our SDKs, so should we treat the rest of this as a P1 as well?