Phoebe: Sohan wanted a way to uniquely identify a reducer run so the words3 can track failures. Currently, to identify a reducer call based on a reducer-callback, a client has to be able to backtrack from the reducer args; this may be impossible if the client has issued multiple calls with the same args, some of which succeeded and some of which failed.
Sohan writes:
if its useful to know how it works for the on-chain version is I just get a tx hash and then await its receipt, then parse the receipt for status
(awaiting receipt polls but wtvr)
would be super nice to get an id for a reducer call that I can check status of
We need to figure out the exact semantics of this, but I imagine something like:
Each client has a global uint64 counter for reducer ids.
When a client invokes a reducer, it increments its counter, attaches it to the FunctionCall message it sends to the server, then returns the id to the caller.
When the reducer finishes, the TransactionUpdate sent to the client is augmented with the same id.
It’s important that other clients are not shown the id; it shouldn’t leak.
How do clients expose this functionality? Is there a function to poll the id? Is the id an additional argument to reducer callbacks? Can the user register a callback on a specific reducer id?
Tyler edit Feb 13: This also may become important for implementing exactly-once semantics between databases as databases would need to deduplicate retried requests. We should revisit this for 1.0.
As discussed internally, this particular ticket needs a proposal because of its implications on the wider distributed systems model of SpacetimeDB. Just needs more thought.
Phoebe: Sohan wanted a way to uniquely identify a reducer run so the words3 can track failures. Currently, to identify a reducer call based on a reducer-callback, a client has to be able to backtrack from the reducer args; this may be impossible if the client has issued multiple calls with the same args, some of which succeeded and some of which failed.
Sohan writes:
We need to figure out the exact semantics of this, but I imagine something like:
FunctionCall
message it sends to the server, then returns the id to the caller.TransactionUpdate
sent to the client is augmented with the same id.Tyler edit Feb 13: This also may become important for implementing exactly-once semantics between databases as databases would need to deduplicate retried requests. We should revisit this for 1.0.