The pull request dashboard publisher holds a repository-scoped Git lease while it delivers side effects and updates the dashboard issue. Most publisher jobs finish in under a minute, but several delivery paths can process all accumulated repository work, so the current 50-minute job timeout and 60-minute lease cannot safely be reduced based on typical runtime alone.
Add explicit, durable per-run bounds for the currently unbounded delivery paths:
- Slack notifications across open non-draft pull requests
- prepared author nudges
- Copilot review requests
- dashboard command replies
- dashboard issue rendering or any other work whose cost grows with the repository's open pull request count
Preserve pending work for later publishers, as the status-comment rollout already does with its 50-item batch. Define bounds using API cost and worst-case runtime, not only pull request count, and ensure retries cannot lose or duplicate external effects.
Once all lock-held work has a reliable upper bound, reduce the publisher job timeout and publisher-lock lease together. The job must always be terminated before its lease can expire, while a crashed publisher should stall its repository for substantially less than the current one-hour maximum.
This follows up on the publisher-starvation work in #347. Acceptance criteria:
- Every delivery path executed while holding the publisher lock has an explicit per-run bound.
- Deferred work is durable and is drained by subsequent targeted or hourly publishers.
- Tests cover partial batches, retries, new work arriving during delivery, and completion across multiple runs.
- Production runtime data supports a shorter job timeout and lease with documented safety margin.
- The stale-lock recovery window is reduced without allowing a live publisher to outlast its lease.
The pull request dashboard publisher holds a repository-scoped Git lease while it delivers side effects and updates the dashboard issue. Most publisher jobs finish in under a minute, but several delivery paths can process all accumulated repository work, so the current 50-minute job timeout and 60-minute lease cannot safely be reduced based on typical runtime alone.
Add explicit, durable per-run bounds for the currently unbounded delivery paths:
Preserve pending work for later publishers, as the status-comment rollout already does with its 50-item batch. Define bounds using API cost and worst-case runtime, not only pull request count, and ensure retries cannot lose or duplicate external effects.
Once all lock-held work has a reliable upper bound, reduce the publisher job timeout and publisher-lock lease together. The job must always be terminated before its lease can expire, while a crashed publisher should stall its repository for substantially less than the current one-hour maximum.
This follows up on the publisher-starvation work in #347. Acceptance criteria: