Skip to content

Conversation

@brandur
Copy link
Contributor

@brandur brandur commented Jan 18, 2026

As reported by #1125, the stuck job detection mechanism currently only
considers client-level timeouts and without properly accounting for the
possibility of worker-level overrides.

Here, make sure to account for worker-level timeouts as well by hosting
the job timeout calculation further up in the executor logic.

Fixes #1125.

@brandur brandur force-pushed the brandur-stuck-worker-timeout branch from a76ba97 to 11838bf Compare January 18, 2026 17:34
@brandur brandur force-pushed the brandur-stuck-worker-timeout branch 3 times, most recently from 9134eaf to a0cd70e Compare January 18, 2026 18:01
…ent-level

As reported by #1125, the stuck job detection mechanism currently only
considers client-level timeouts and without properly accounting for the
possibility of worker-level overrides.

Here, make sure to account for worker-level timeouts as well by hosting
the job timeout calculation further up in the executor logic.

Fixes #1125.
@brandur brandur force-pushed the brandur-stuck-worker-timeout branch from a0cd70e to 7eebbb3 Compare January 18, 2026 18:02
}

return context.WithCancel(ctx)
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This was doing very little (it's the same as a if jobTimeout > 0 { check) and I needed the conditional for something else, so I just pulled it into execute.

@brandur brandur requested a review from bgentry January 18, 2026 18:05
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.

Stuck job evaluation doesn't take into account worker-level job timeouts

2 participants