Developer staffing guide · 8 minute read ·
Test what happens when a background job outlives its lease — September 11 review
Reproduce a lost worker lease without letting two workers finish the same job.
Readiness check
Is the handoff ready?
Use this table before you send the first ticket. Fix the weak spots while access is still limited.
| Area | Ready | Needs work |
|---|---|---|
| Question | One observable worker lease expiry outcome | A request to inspect the whole system |
| Fixture | a disposable queue with one job paused before its final write and a lease shorter than the pause | Customer data or shared credentials |
| Evidence | job ID, worker ID, lease time, renewal attempt, takeover time, write count, and terminal state | A pass label without observed values |
| Approval | The platform owner chooses lease duration, retry policy, and production rollout. | The contractor changes production alone |
Reproduce the worker lease expiry failure safely
A slow worker keeps running after its lease expires while a second worker picks up the same job. Start with one case that can fail without touching customer records or production infrastructure. Write the expected result, stop condition, and reviewer beside the fixture.
Use a disposable queue with one job paused before its final write and a lease shorter than the pause. Label every identity and artifact so a reviewer can distinguish test evidence from a live record.
Leave enough evidence for a second person — September 11 review
Capture job ID, worker ID, lease time, renewal attempt, takeover time, write count, and terminal state. Include the source revision and test time. If behavior changes between runs, retain both results.
The platform owner chooses lease duration, retry policy, and production rollout. A remote programmer can prepare the fixture, run bounded checks, and explain the result. New policy, privileged access, and release approval stay with the named owner.
Copy-ready brief
Paste this into your hiring request
Test one bounded worker lease expiry case against written acceptance rules.
a disposable queue with one job paused before its final write and a lease shorter than the pause
Record job ID, worker ID, lease time, renewal attempt, takeover time, write count, and terminal state.
The platform owner chooses lease duration, retry policy, and production rollout.
Buyer questions
Questions about planning the role
What should the first run prove?
It should show the expected worker lease expiry result for one controlled fixture.
What belongs in the handoff?
Include job ID, worker ID, lease time, renewal attempt, takeover time, write count, and terminal state, the source revision, and any untested condition.
Who approves a production change?
The platform owner chooses lease duration, retry policy, and production rollout.
Sources
Planning references
These links explain the security, code review, and worker classification points used in this guide.
- NIST Secure Software Development FrameworkNIST guidance for managing software development risk.
- GitHub pull request reviewsFirst-party documentation for review and approval.