Add blacklist/whitelist of signal and synchronous update types

[mfateev]

Is your feature request related to a problem? Please describe. Signals, even ones that workflow doesn't care about, still consume workflow history. In some use cases, signals are expected only in certain workflow states, and signals received in other states should be rejected.

Describe the solution you'd like Workflow should support blacklisting and whitelisting signal and update types it cares about. Blacklisted signals and updates are rejected immediately without updating the mutable state and the history.

[lorensr]

Implementation: At Workflow Execution start time, you can specify an allow/denylist. List is mutable by command from Workflow.

In future, if we have a way for Workers to tell Server per-WorkflowType configuration, a default allow/denylist could be colocated with the Workflow definition, which in many cases would be better DX IMO.

[danthegoodman1]

And update on this? We've had to move a lot off temporal because of this

[danthegoodman1]

Ideally we'd want to just be able to dynamically change an allow-list

[lorensr]

@danthegoodman1 You can currently implement an Update validation handler (in all SDKs but PHP and TS, which is coming soon) that rejects any Updates that aren't in your (dynamic) allowlist so they won't be included in History. See Validation phase: https://docs.temporal.io/workflows#update

[danthegoodman1]

Yeah problem with that is mixing timeouts and such becomes hacky, but it’s a workaround