📌 Description
CommitmentRules in contracts/commitment_core/src/lib.rs carries a
grace_period_days field, but check_violations (line ~983) and
get_violation_details (line ~1008) appear to flag duration/loss violations without
honouring that grace window. A provider in a temporary drawdown during the declared
grace period can therefore be marked violated prematurely.
This issue makes grace_period_days a real invariant in the violation logic.
🎯 Requirements and Context
- During the grace window, loss-limit and expiry checks must be relaxed per the documented
grace_period_days semantics.
- Time math must use
shared_utils::TimeUtils with checked arithmetic (no expires_at + grace overflow).
- Must not weaken violation detection outside the grace window — preserve
test_check_violations_* snapshots.
get_violation_details return tuple semantics must stay backward-compatible.
🛠️ Suggested Execution
1. Fork the repo and create a branch
git checkout -b feature/grace-period-enforcement
2. Implement changes
- Update
check_violations and get_violation_details in contracts/commitment_core/src/lib.rs to factor in grace_period_days.
- Add
/// docs describing grace semantics; update docs/commitment_core/SEMANTICS.md.
3. Test and commit
- Extend
contracts/commitment_core/src/tests.rs.
- Run:
cargo test --target wasm32v1-none --release
- Edge cases: violation inside grace, violation after grace, grace=0, grace causing expiry overflow.
Example commit message
feat: enforce grace_period_days in commitment violation checks
✅ Guidelines
- Minimum 95% test coverage on the new/changed lines.
- Document grace semantics clearly.
- Timeframe: 96 hours.
🏷️ Labels
type-feature · area-contracts · MAYBE REWARDED · GRANTFOX OSS · OFFICIAL CAMPAIGN
💬 Community & Support
- Join the CommitLabs contributor Discord to coordinate and get unblocked fast: https://discord.gg/WV7tdYkJk
- Introduce yourself before starting to avoid duplicate work.
- Maintainers triage actively and review fast.
📌 Description
CommitmentRulesincontracts/commitment_core/src/lib.rscarries agrace_period_daysfield, butcheck_violations(line ~983) andget_violation_details(line ~1008) appear to flag duration/loss violations withouthonouring that grace window. A provider in a temporary drawdown during the declared
grace period can therefore be marked violated prematurely.
This issue makes
grace_period_daysa real invariant in the violation logic.🎯 Requirements and Context
grace_period_dayssemantics.shared_utils::TimeUtilswith checked arithmetic (noexpires_at + graceoverflow).test_check_violations_*snapshots.get_violation_detailsreturn tuple semantics must stay backward-compatible.🛠️ Suggested Execution
1. Fork the repo and create a branch
2. Implement changes
check_violationsandget_violation_detailsincontracts/commitment_core/src/lib.rsto factor ingrace_period_days.///docs describing grace semantics; updatedocs/commitment_core/SEMANTICS.md.3. Test and commit
contracts/commitment_core/src/tests.rs.cargo test --target wasm32v1-none --releaseExample commit message
✅ Guidelines
🏷️ Labels
type-feature·area-contracts·MAYBE REWARDED·GRANTFOX OSS·OFFICIAL CAMPAIGN💬 Community & Support