Handle unrepresentable Scheduling booking horizons safely
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 55/100
Research direction
Trace Scheduling availability handling for exact-time and arrival-window offerings, focusing on the Chrono date-addition path described in the reproduction. Add focused regression tests for the accepted upper boundary in both modes, then verify that an accepted horizon produces no panic and follows the chosen refusal or saturation behavior.
Written by the indexing model from the issue text.
Description
What Happened
Scheduling policy validation accepts any nonzero u32 horizonDays. Availability later uses infallible Chrono addition for both exact-time and arrival-window offerings. An operator-authored value such as 4294967295 can therefore panic the availability request task when the computed date is outside Chrono's representable range.
The public availability query span is separately bounded, and callers cannot set the policy horizon. This requires malformed trusted configuration and does not bypass authorization or capacity checks.
Expected Behavior
Availability should never panic for a policy accepted by authoring validation. Use checked date arithmetic with a defined saturation/refusal behavior, or establish and validate a product-level maximum horizon for both scheduling modes.
Reproduction
- Author an otherwise valid exact-time or arrival-window offering with
horizonDays: 4294967295. - Start Scheduling and request availability for that offering.
- Observe Chrono's
DateTime + TimeDelta overflowedpanic path.
Add focused exact-time and arrival-window regression tests at the accepted upper boundary.
Environment
Found while reviewing PR #1092 at commit 68e3060fb. This is beta hardening for invalid operator configuration rather than a remote-input or ledger-integrity issue.
- Dominant language
- Rust
- Stars
- 2
- Forks
- 0
- Avg merge
- 9h 14m
- Merged PRs (30d)
- 241
Getting set up
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from registrystack/registry-stack
-
agent-ready area:breg bug criticality:p3 triage:needs-implementation
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
registrystack/registry-stack#1941 ·
Maintainers usually reply within 1 day
-
area:casework bug criticality:p2 rust
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
registrystack/registry-stack#1936 ·
Maintainers usually reply within 1 day
-
area:casework bug criticality:p3 rust
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
registrystack/registry-stack#1934 ·
Maintainers usually reply within 1 day
-
area:release area:scheduling bug criticality:p3 triage:needs-implementation
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
registrystack/registry-stack#1909 ·
Maintainers usually reply within 1 day
-
area:release bug
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
registrystack/registry-stack#1874 ·
Maintainers usually reply within 1 day
All issues in registrystack/registry-stack
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
rescript-lang/rescript#8765 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
chroma-core/chroma#7879 ·
Maintainers usually reply within 1 day
-
priority middle
Difficulty 1/5 Under an hour Newbie friendliness 72/100
KATO-Hiro/AtCoderClans#12838 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day