search

dhiaayachi / temporal

Temporal service
https://docs.temporal.io
MIT License
0 stars 0 forks source link

Take additional factors into account for suggesting continue-as-new #410

Open dhiaayachi opened 2 months ago

dhiaayachi commented 2 months ago

The recently added mechanism for the server to suggest workflow continue-as-new is based on history event length and byte size. Users can hit other limits such as number of signals received and scheduled activities, the server suggestion should take those factors into account to help users out.

See for reference: https://github.com/temporalio/api/blob/ae312b0724003957b96fb966e3fe25a02abaade4/temporal/api/history/v1/message.proto#L180

dhiaayachi commented 1 month ago

Thank you for reporting this issue. The server currently suggests continue-as-new based on the history event length and byte size. It would be helpful to have it take other factors into account, such as number of signals received and scheduled activities.

You can work around this by monitoring your Workflow Executions and manually triggering continue-as-new if you see that the Event History is becoming too large or if you are reaching other limits. The Temporal SDKs all provide a ContinueAsNew API that you can use to do this.

dhiaayachi commented 1 month ago

Thanks for reporting this! We agree that the server suggestion for continue-as-new should take factors like signals and scheduled activities into account to provide more comprehensive guidance to users.

For now, you can monitor these limits yourself to understand when you're approaching them.

dhiaayachi commented 1 month ago

Thanks for reporting this!

The Temporal Server currently suggests a Continue-As-New based only on history event length and byte size. This feature request is a good idea, and we'll definitely consider it in the future.

In the meantime, you can implement logic in your Workflow to check these additional factors and trigger a Continue-As-New manually if needed.