Demo
A nightly batch that stays inside the limits
Step through an unattended run of a command-line tool against an invented work-queue service. The tool keeps its own request budget below the service’s limit, waits out three kinds of throttling, skips a malformed item without stopping, checks afterwards that its work registered, and on a rerun sends nothing twice.
This is a simulation. The service, its limits, its work items and every throttle are invented and scripted, and time passes on a simulated clock, so no wait is real. No request is made: each one is only counted in your browser. Nothing leaves your browser or is kept, and reloading the page starts again.
Run controls
Simulated clock: Day 1, 02:00:00
Walks the queue and says what it would do, sends no action and writes nothing to the state file. Set it before a run starts.
The system timer starts run 1 at 02:00 on day 1. Press the Next step button to take it one step at a time.
Request budget
Requests in the last 60 seconds
0 of 9 used. Room to send.
The service documents 12 requests in any 60 seconds. The last 3 cells are never used: the tool pauses at 9. Busiest 60 seconds this run: 0.
Status file
Live progress
- State
- Ready, not started
- Clock
- Day 1, 02:00:00
- Run
- None yet
- Item
- 0 of 15
- Handled this run
- 0
- Skipped this run
- 0
- Throttles this run
- 0
- Actions today
- 0 of 20
- Verifier
- Not run yet
Queue
15 items
- W-01: Archive closed folder 14. Waiting
- W-02: Compress log bundle 3. Waiting
- W-03: Tag photo set 21. Waiting
- W-04: Rename draft 8. Waiting
- W-05: Archive closed folder 15. Waiting
- W-06: Compress log bundle 4. Waiting
- W-07: Tag (no target). Waiting
- W-08: Rename draft 9. Waiting
- W-09: Archive closed folder 16. Waiting
- W-10: Compress log bundle 5. Waiting
- W-11: Tag photo set 22. Waiting
- W-12: Rename draft 10. Waiting
- W-13: Archive closed folder 17. Waiting
- W-14: Compress log bundle 6. Waiting
- W-15: Tag photo set 23. Waiting
Run log
Every step appears here with its time on the simulated clock: each request, each pause and wait, each skip, and the verifier’s answer.
State file
Kept across runs
- Handled items
- None yet
- Daily counter
- Day 1: 0 of 20
- Problem items
- None recorded
Held in page memory here. The real tool writes its state and status files to its own data folder.
The tool’s rules
- The service documents a limit of 12 requests in any 60 seconds. The tool keeps its own budget of 9, and pauses before it would go past it.
- Only a throttled request makes the tool read the retry hint: a number of seconds, or a time on the service’s clock.
- When a throttle has no retry hint, or from the second throttle in a row, it backs off. The first, second and third throttle in a row wait 5, 10 and 20 seconds; after that the wait doubles, but never past 30. A longer hint still wins.
- Every handled item goes in the state file, so a rerun never sends it again. The file also counts the day’s actions, up to a cap of 20.
- An item that cannot be handled is skipped and recorded, and the run goes on.
- After the run, the verifier asks the service what it recorded and checks every handled item is there.
What the demo shows
- A budget of its own, below the limit. Every request, throttled ones included, is counted in a sliding 60 second window. The tool pauses before a request that would take it past 9, so the service’s limit of 12 is never reached.
- Throttling handled three ways. A retry hint in seconds is followed as given. A hint given as a time on the service’s clock is turned into a wait. A throttle with no hint, and any throttle after the first in a row, brings in exponential backoff that doubles and then stops growing at a cap.
- Nothing done twice. Each handled item is written to a state file. Run it again the same day and every item is found there, so no action is sent. The next day the counter starts again and only new items are handled.
- Skip, record, go on. A malformed item is skipped and recorded for a person to look at, and the rest of the batch still runs.
- Checked afterwards. After the run, one request asks the service what it recorded, and the verifier checks every handled item is there.
- Built to run unattended. A system timer starts the run, a status file reports progress as it goes, and a dry run shows what would happen without sending anything.