Skip to content

Conversation

@alexshtin
Copy link
Contributor

@alexshtin alexshtin commented Jul 18, 2020

What changed?
If WorkflowExecutionTimeout is reached on workflow, workflow is timed out in spite of cron schedule.
Also fix GetBackoffForNextSchedule to return right result if closeTime is before startTime.

Why?
Fixing bugs discovered in #394.

How did you test it?
Added new unit tests.

Potential risks
No risks.

@alexshtin alexshtin requested a review from samarabbas July 18, 2020 01:04
return NoBackoff
}

if closeTime.Before(startTime) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't believe this is the right fix. If startTime comes after closeTime, then it means some other event triggered invocation of this code path like workflow timeout. In this case we should still try to fire the cron on previous value so we should just return start the delta between startTime and closeTime immediately.

Copy link
Contributor

@samarabbas samarabbas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes in timerQueueActiveTaskExecutor.go looks good. But you need to slightly adjust the logic in GetBackoffNextSchedule based on the comment I left.

@alexshtin alexshtin force-pushed the fix/workflow-timeout branch from 0abb1c2 to e1b6c44 Compare July 20, 2020 20:29
@alexshtin alexshtin merged commit c37db07 into temporalio:master Jul 21, 2020
@alexshtin alexshtin deleted the fix/workflow-timeout branch July 21, 2020 04:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants