Clients should generate an ID for each reducer call

[cloutiertyler]

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.

[cloutiertyler]

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.

[gefjon]

Moving to tracking, as we have no plans to do this within the 0.12 or 1.0 windows.