retoor
af080fe68e
- Approval: re-prompt unknown answers (max 3), shell-only affirmative guidance recovery; destructive actions stay strict - GoalVerifier subagent with strict JSON verdicts, bounded follow-up rounds, nonzero exit plus open turn on unverified one-shots - Retrieval eval (Hit@K/MRR/nDCG/Context Precision), FTS cascade with title weighting, query/read event logging, --eval-retrieval CLI - Supervisor caps (8 parallel, 64 records) and scheduler hardening (4 fires/tick, per-schedule lease, stated misfire policy) - Sandbox box resource trio: 2g/2.0/256 at create, best-effort update for existing boxes, rm -f recovery pointer - Research archive: 12 subjects, 667 sources, 27 conclusions; suites 979 + 16 green
52 lines
2.7 KiB
Markdown
52 lines
2.7 KiB
Markdown
# APScheduler User Guide
|
|
|
|
## Metadata
|
|
|
|
| Field | Value |
|
|
|---|---|
|
|
| Institute | Molodetz Institute — Research & Retrieval Division |
|
|
| Subject | background-work-limits |
|
|
| Document type | Source Dossier |
|
|
| Tier | 1 |
|
|
| Source title | APScheduler User Guide |
|
|
| Source URL | https://apscheduler.readthedocs.io/en/3.x/userguide.html |
|
|
| Source publisher / author | APScheduler |
|
|
| Source type | vendor docs |
|
|
| Source date (published) | Unknown — not stated (living documentation page) |
|
|
| Date researched | 2026-10-18 |
|
|
| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
|
|
| Research method | both |
|
|
| Confidence | High |
|
|
| Status | Active |
|
|
|
|
## Summary
|
|
|
|
The APScheduler guide supplies tai's scheduler policy vocabulary: max_instances defaults to 1 (a new fire while the previous run lives counts as a misfire), coalescing rolls queued missed executions into one trigger, and misfire_grace_time decides whether a late execution still runs (which can fire several runs in succession).
|
|
|
|
## Key findings
|
|
|
|
- "By default, only one instance of each job is allowed to be run at the same time. This means that if the job is about to be run but the previous run hasn't finished yet, then the latest run is considered a misfire."
|
|
- "It is possible to set the maximum number of instances for a particular job that the scheduler will let run concurrently, by using the `max_instances` keyword argument when adding the job."
|
|
- "If coalescing is enabled for the job and the scheduler sees one or more queued executions for the job, it will only trigger it once. No misfire events will be sent for the 'bypassed' runs."
|
|
- Late execution against `misfire_grace_time` "can lead into the job being executed several times in succession."
|
|
|
|
## Pros / strengths
|
|
|
|
- Three orthogonal knobs (overlap, coalescing, grace) that decompose tai's scheduler decisions cleanly: tai takes max_instances 1 plus always-coalesce and skips grace windows as unneeded complexity.
|
|
- Documents the failure mode each knob prevents, so tai's simpler choices stay explicit rather than accidental.
|
|
|
|
## Cons / limitations / caveats
|
|
|
|
- Single-process scheduler semantics; tai's compare-and-swap claim across processes goes beyond what this page covers.
|
|
- No per-tick firing cap concept; tai's burst bound comes from the supervisor side (global parallel cap), not from here.
|
|
|
|
## Relevance to tai
|
|
|
|
Direct template for the scheduler half: one live run per repeating schedule (lease-checked, Temporal-Skip style), missed intervals coalesced into one fire (already tai's behavior, now specified), and no auto-retry of failed runs (loud `last_status` instead).
|
|
|
|
## Changelog
|
|
|
|
| Date | Change |
|
|
|---|---|
|
|
| 2026-10-18 | Initial dossier created. |
|