Repository navigation
v3.30.6: release claims when recurring tasks advance - #99
Merged
Merged
Conversation
puretensor
force-pushed
the
audit/recurrence-release-claim
branch
from
September 12, 2026 09:59
49ab488 to
2f645b1
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Completing a claimed recurring task advances its deadline but leaves it
in_progress, so the next occurrence cannot be claimed. Completing snoozed recurring work similarly retains the previous snooze.The recurrence transaction now resets the next occurrence to
todo/legacypendingand clearssnoozed_until, preserving the UUID and PT-N. It also checks current terminal state inside the transaction: completing a stale reference cannot revive a dismissed recurrence. The recurrence guide now describes in-place advancement and actual supported grammar/CLI options.Original-code evidence at
a95a43b:cargo test -p ptask-core recurring_completion_releases --lockedfailed because the next occurrence remainedin_progressinstead oftodo. The fixed regression covers both fixed and completion-relative schedules, claimed and snoozed states, stable identity, matching recurrence deadline and a subsequent successful claim. A separate stale-reference test checks that a dismissed task, schedule and event cursor remain unchanged. Severity: medium; recurring agent work becomes unavailable after its first completion.Validation on Rust 1.98.1, all exit 0:
Builds used a dedicated audit target directory and CPU fence; database tests used disposable stores.
Compatibility: active recurring completion releases the previous occurrence's claim/snooze. Terminal recurring tasks must be explicitly reopened before another completion. No schema change, dependency update or production activity. Workspace, internal requirements, lockfile and manpage bump together to v3.30.6. Independent branch from
mainata95a43b; reconcile version metadata when landing multiple independent audit PRs. No overlapping open issue or PR. Remote CI is separate from the executed local results above.Additional validation limits
Native-feature tests include existing model-dependent cases that can return early when assets are unavailable; model-loaded coverage is not claimed. Local builds were debug workspace builds, not release or cross-target builds. Dependency-policy checks passed with pre-existing yanked
chacha20 0.10.0and unusedBSD-2-Clauseallowance warnings. The upstream-backed chacha20 correction is isolated in PR #102, not folded into this defect branch.