feat(workflow): Add historySizeInBytes and continueAsNewSuggested to WorkflowInfo (#695) #1223
Conversation
lorensr
changed the title
| const MAX_EVENTS = 40_000; | ||
| const BATCH_SIZE = 100; | ||
| while (workflow.workflowInfo().historyLength < MAX_EVENTS) { | ||
| await Promise.all(new Array(BATCH_SIZE).fill(undefined).map((_) => workflow.sleep(1))); |
There was a problem hiding this comment.
nit: I'd use an upsert search attributes instead, it's cheaper to run.
There was a problem hiding this comment.
It is actually pretty fast, and even against the cloud, it will succeed in just 20 round trips (the actual server settings are 4K events, not 40K)
packages/client/src/types.ts
Outdated
| @@ -36,6 +36,15 @@ export interface WorkflowExecutionInfo { | |||
| taskQueue: string; | |||
| status: { code: proto.temporal.api.enums.v1.WorkflowExecutionStatus; name: WorkflowExecutionStatusName }; | |||
| historyLength: number; | |||
| /** | |||
|  * Size of Workflow history in bytes until the current Workflow Task. | |||
There was a problem hiding this comment.
until the current Workflow Task don't really make sense in this structure. There is no "current workflow task". Similar for This value changes during the lifetime of an Execution. I don't think it adds real value in this context.
Last thing: historySize is available in server versions >= 1.20 (ie. starting with 1.20, not greater than)
There was a problem hiding this comment.
Updated comment
|
@antlai-temporal Just one last minor thing, then I think we can move on. |
What was changed
Makes visible to workflows the new info fields historySizeInBytes and continueAsNewSuggested
Why?
Makes it easier for workflow code to decide when to continueAsNew() before history becomes too large
Checklist
Closes
[Feature Request] Add
WorkflowInfo.historySizeInBytes#695How was this tested:
A new system test and unit test added
Any docs updates needed?
jsdoc of the new fields