SDKs should expose history length and size via Workflow info

[bergundy]

History length:

• Golang - Add workflow.GetInfo(ctx).GetCurrentHistoryLength() sdk-go#851
• TS - [Feature Request] Expose history size to Workflow code sdk-typescript#357
• Java - Provide WorkflowInfo#getHistoryLength() sdk-java#1300
• Python - Add get_current_history_length() to workflow info sdk-python#73
• PHP - [Feature Request] Expose history length via Workflow info sdk-php#222
• .NET - [Feature Request] Expose history-related properties to workflow sdk-dotnet#122

History size and "should continue as new":

• Server - Communicate shouldContinueAsNew to Workers  temporal#2726 (Expose history size to workflows temporal#3055)
• Golang - Workflow API to check if ContinueAsNew is required sdk-go#628
• Core - [Feature Request] Expose history_size_in_bytes and should_continue_as_new sdk-core#564
• TS - [Feature Request] Add WorkflowInfo.historySizeInBytes sdk-typescript#695
• Java - Add new workflow info fields sdk-java#1853
• Python - Expose history size and continue-as-new-suggested sdk-python#361
• PHP - TODO
• .NET - [Feature Request] Expose history-related properties to workflow sdk-dotnet#122

[lorensr]

Related:

We should give Workflow.isContinueAsNewNeeded flag to the SDKs. And it should be coming from the service.

https://temporaltechnologies.slack.com/archives/C01FT8U10GK/p1643400086752909?thread_ts=1643398281.925129&cid=C01FT8U10GK

[lorensr]

I think we should expose shouldContinueAsNew as well in all SDKs.

1. If server is able to take into account other things, then it's better than history length/size
2. This:

if (workflowInfo().shouldContinueAsNew) {
  cAN()
}

is shorter & easier to read/understand compared to:

if (workflowInfo().historyLength < 10_000 && workflowInfo().historySize < 10_000_000) {
  cAN()
}

3. We'll no longer need to teach people the right numbers to use

[cretz]

I think we should expose shouldContinueAsNew as well in all SDKs.

Concur, when available in server (no benefit in supporting before server). Or is it already available in server? What is the logic there and is it configurable?

[mjameswh]

It will be important to mention in documentation the fact that relying on these properties is useless and dangerous if using an older server.

[cretz]

We could make it a capability and error (i.e. wft failure) if invoked for older server. But I think this is a good enough reason to not even expose this until it is available on cloud.

[cretz]

Note, we should call this "continue as new suggested" across all SDKs I think.

[cretz]

A caveat that SDKs need to note here: these three values may be delayed if viewed via query. Since the value is on wft start, a query-only poll response won't have updated history. So if you, say, sent a signal to start far-out 50 timers, and then, even after already in history stored, sent just a query, there is no new wft and therefore no value updates even though current event count is actually quite different on the server.

Basically every SDK needs to document that these values may be delayed if accessed in a query.