[Feature Request] Expose `updateId` to Update handlers

[mjameswh]

Describe the solution you'd like

A Workflow Update carries an updateId field used to dedup updates. However, server side dedup is per-workflow-execution. Workflow implementers may have legitimate reasons to extend that guarantee across continue-as-new boundary.

Doing that effectively require access to the updateId, which is not exposed to the update handler at the moment.

We should make this information accessible through an updateInfo() function.

Extra thoughts

updateInfo() would rely on an asyncLocalStorage set just before invoking interceptors. It might be interesting to make that asyncLocalStorage more general, so that it also get set while handling queries and signals, thus providing more general execution context tracking, with only marginal extra difficulty. This could possibly allow providing similar signalInfo() and queryInfo() APIs (though there seems to be very limited use cases for that ATM), but also allow detecting stuff like workflow commands started from a query handler.

[Quinn-With-Two-Ns]

This feature also exists in the Go SDK

[mjameswh]

Note that, even though the update handler don’t receive the updateId, workflow interceptors do. Therefore, in the mean time, one can capture the updateId form an interceptor, and make it accessible to your actual update handler code using an async local storage...