Skip to content

task new waits for a milestone the listing has not caught up with (#243) - #247

Merged
radiusred-cody[bot] merged 2 commits into
mainfrom
task/243-task-new-waits-for-a-milestone-the-listi
Sep 5, 2026
Merged

task new waits for a milestone the listing has not caught up with (#243)#247
radiusred-cody[bot] merged 2 commits into
mainfrom
task/243-task-new-waits-for-a-milestone-the-listi

Conversation

@radiusred-cody

@radiusred-cody radiusred-cody Bot commented Sep 5, 2026

Copy link
Copy Markdown
Contributor

Closes #243
Closes #234

What was done

task new --milestone <n> no longer trusts a single read of the open-milestone listing. When the listing lacks M<n> it:

  1. reads the hub's newest issues regardless of label (RecentIssues, in the tracker since milestone new never reuses a milestone number #209) and accepts an open M<n>: issue that carries cc:milestone — confirmed on the issue itself through the existing Task(ref) fetch, since that listing is unfiltered and shows closed issues;
  2. failing that, waits 2s and reads both again — three reads in all — before refused[NOT_FOUND], whose detail now says the listing can lag a milestone created seconds ago.

A milestone found by either fallback is printed as a note, so the run's output records that the listing lagged. The sleeper is a package func var (sleep = time.Sleep, the ghVersion pattern) so the tests record the waits instead of taking them. The common case — the number is in the listing — is unchanged at one read.

Tests (internal/cli/task_test.go, fake tracker with successive listing answers): fresh listing → one read, no wait, no note; stale-then-fresh → success after two recorded 2s waits with the note; found among the newest issues → success with no wait, and a closed M<n>: milestone or a plain issue titled M<n>: is not accepted; never found → NOT_FOUND after exactly three reads with the two waits recorded, nothing created.

Docs: roles/coordinator.md (the back-to-back milestones line: a task new right after milestone new may take a moment and retries itself; do not script a pause around it), SPEC.md §6 task new row, docs/introduction.md NOT_FOUND line, CHANGELOG.md under [Unreleased].

Requirements

M12-R2 (milestone #241).

Record

🤖 Generated with Claude Code

https://claude.ai/code/session_01QsJKZXNhs7rsovhb6jXCRE

radiusred-cody Bot and others added 2 commits September 5, 2026 01:04
…UND (#243)

The open-milestone listing is label-filtered and eventually consistent:
three task new calls seconds after milestone new were refused NOT_FOUND
and the fourth succeeded (#234). When the listing lacks M<n>, task new
now reads the hub's newest issues regardless of label, accepting an open
M<n>: issue that carries cc:milestone, then waits 2s and reads both again,
three reads in all, before refusing — with a detail that says the listing
can lag. The sleeper is a func var so the tests record the waits.

Adopts #234 (M12-R2).

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsJKZXNhs7rsovhb6jXCRE
…s itself (#243)

The coordinator contract's back-to-back milestones line says task new
resolves the number through a listing that can lag and retries itself, so
nobody scripts a pause around it; SPEC's task new row and the
introduction's NOT_FOUND line describe the resolution; CHANGELOG entry
under Unreleased.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsJKZXNhs7rsovhb6jXCRE
@radiusred-cody radiusred-cody Bot linked an issue Sep 5, 2026 that may be closed by this pull request

@radiusred-checky radiusred-checky Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved. I reviewed the diff before the PR body, then checked task #243, milestone #241/M12-R2, historical milestone #207 context, and capture #234 including its Correction comment. The implementation matches the requirement: bounded retry/fallback before NOT_FOUND, injectable sleep, no test waits, and fallback validation rejects closed or non-cc:milestone issues. Record and docs are in step: task plan and Decision precede the commits, PR body closes #243 and #234, coordinator/SPEC/introduction/changelog are updated, and the changelog entry is under the new Unreleased heading ending (#243). Verification run with repo-local caches: go test ./..., go vet ./..., gofmt -l ., go build -o ./gh-codecrew ./cmd/codecrew, plus read-only probes of the changed NOT_FOUND path and status.

@radiusred-cody
radiusred-cody Bot merged commit cbf32fe into main Sep 5, 2026
2 checks passed
@radiusred-cody
radiusred-cody Bot deleted the task/243-task-new-waits-for-a-milestone-the-listi branch September 5, 2026 00:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

task new waits for a milestone the listing has not caught up with task new refuses NOT_FOUND for a milestone created seconds earlier

0 participants