Skip to content

Bump pnpm/action-setup from 5 to 6#1

Open
dependabot[bot] wants to merge 1 commit intomainfrom
dependabot/github_actions/pnpm/action-setup-6
Open

Bump pnpm/action-setup from 5 to 6#1
dependabot[bot] wants to merge 1 commit intomainfrom
dependabot/github_actions/pnpm/action-setup-6

Conversation

@dependabot
Copy link
Copy Markdown

@dependabot dependabot Bot commented on behalf of github Apr 25, 2026

Bumps pnpm/action-setup from 5 to 6.

Release notes

Sourced from pnpm/action-setup's releases.

v6.0.0

Added support for pnpm v11.

Commits
  • 26f6d4f fix: use npm co-located with the action node binary (#239)
  • 903f9c1 fix: update pnpm to 11.0.0-rc.5
  • bdf0af2 test: add strict version-match jobs to reproduce #225 / #227
  • 71c9247 fix: pnpm self-update binary shadowed by bootstrap on PATH (#230)
  • 078e9d4 fix: update pnpm to 11.0.0-rc.2
  • 08c4be7 docs(README): update action-setup version
  • 5798914 chore: update .gitignore
  • ddffd66 fix: remove accidentally committed file
  • b43f991 fix: update pnpm to 11.0.0-rc.0
  • 3852509 README.md: bring versions up-to-date (#222)
  • Additional commits viewable in compare view

@dependabot dependabot Bot added dependencies Pull requests that update a dependency file github_actions Pull requests that update GitHub Actions code labels Apr 25, 2026
@jimdou jimdou self-requested a review as a code owner April 28, 2026 06:48
jimdou added a commit that referenced this pull request Apr 29, 2026
…ault + activity log no longer drowns in bus events

Three connected bugs and one polish ask:

1. Phantom claims every 5s after a run finishes
The scheduler treated 'review' status as runnable. After the executor
finished a run and parked it in awaiting_review, the planner kept
picking the SAME sub-task on every orchestrator tick. Each pick:
- created a new claim (run-launcher.ts:112)
- tried to create a worktree on a branch that already existed
- threw — but the claim was already on disk, orphaning forever

Fix:
- scheduler.ts: new isAlreadyHandled() that filters status='running'
  and status='review'. The candidate filter combines this with the
  existing isTerminal() check.
- run-launcher.ts: wrap ensureWorktree in try/catch. On failure we
  archiveClaim() the just-created claim and push a typed
  'worktree_failed:<msg>' skip reason instead of leaking. Defense in
  depth: even if the scheduler missed a case, the claim no longer
  zombies.
- One-time housekeeping: archived the 11 orphaned claims sitting in
  ~/Dev/test-backlog-demo/.backlog/claims/active/ from this bug.

2. Topbar Stop didn't switch back to Play
Symptom of #1: every 5s a new claim was being made for a stuck
sub-task, and the SSE stream kept the UI in 'something is happening'
mode. With the planner no longer re-launching, hasInFlightRun
correctly drops to false when the run hits awaiting_review and the
topbar visual transitions Stop → Play, all-done toast fires.

3. Activity log flooded with naked 'claim.changed' lines
Bus events (claim.changed / subtask.changed / task.changed /
run.changed / orchestrator.changed) carry no payload — they're a
hint to the BOARD that something changed, not user-visible activity.
Removed the bus subscription from ActivityBanner; the activity SSE
already surfaces every meaningful event with run_id + message
(executor.start, agent.bash, run.committed, run.pushed, etc.).
App.svelte still listens to /events for board-refresh purposes.

4. Worktree mode at top, default Direct
CreateTaskDialog: the worktree-mode dropdown was buried under all
the commit/push/PR toggles. Moved it to the top of the Execution
fieldset (it's the single biggest decision per task) and switched
the default from 'isolated_worktree' to 'direct'. The schema +
task-service defaults follow. Note in the schema/UI is honest about
the executor still using a worktree under the hood until 'direct'
is wired downstream.

Polish: 'Met en file la PR via gh pr merge --squash --auto' —
indecipherable to a non-technical user. Replaced both languages
with 'Squash-merge the PR as soon as it's green. If your branch
has required CI checks or reviews, the merge waits for them.'

247/247 still pass.
jimdou added a commit that referenced this pull request Apr 30, 2026
…ault + activity log no longer drowns in bus events

Three connected bugs and one polish ask:

1. Phantom claims every 5s after a run finishes
The scheduler treated 'review' status as runnable. After the executor
finished a run and parked it in awaiting_review, the planner kept
picking the SAME sub-task on every orchestrator tick. Each pick:
- created a new claim (run-launcher.ts:112)
- tried to create a worktree on a branch that already existed
- threw — but the claim was already on disk, orphaning forever

Fix:
- scheduler.ts: new isAlreadyHandled() that filters status='running'
  and status='review'. The candidate filter combines this with the
  existing isTerminal() check.
- run-launcher.ts: wrap ensureWorktree in try/catch. On failure we
  archiveClaim() the just-created claim and push a typed
  'worktree_failed:<msg>' skip reason instead of leaking. Defense in
  depth: even if the scheduler missed a case, the claim no longer
  zombies.
- One-time housekeeping: archived the 11 orphaned claims sitting in
  ~/Dev/test-backlog-demo/.backlog/claims/active/ from this bug.

2. Topbar Stop didn't switch back to Play
Symptom of #1: every 5s a new claim was being made for a stuck
sub-task, and the SSE stream kept the UI in 'something is happening'
mode. With the planner no longer re-launching, hasInFlightRun
correctly drops to false when the run hits awaiting_review and the
topbar visual transitions Stop → Play, all-done toast fires.

3. Activity log flooded with naked 'claim.changed' lines
Bus events (claim.changed / subtask.changed / task.changed /
run.changed / orchestrator.changed) carry no payload — they're a
hint to the BOARD that something changed, not user-visible activity.
Removed the bus subscription from ActivityBanner; the activity SSE
already surfaces every meaningful event with run_id + message
(executor.start, agent.bash, run.committed, run.pushed, etc.).
App.svelte still listens to /events for board-refresh purposes.

4. Worktree mode at top, default Direct
CreateTaskDialog: the worktree-mode dropdown was buried under all
the commit/push/PR toggles. Moved it to the top of the Execution
fieldset (it's the single biggest decision per task) and switched
the default from 'isolated_worktree' to 'direct'. The schema +
task-service defaults follow. Note in the schema/UI is honest about
the executor still using a worktree under the hood until 'direct'
is wired downstream.

Polish: 'Met en file la PR via gh pr merge --squash --auto' —
indecipherable to a non-technical user. Replaced both languages
with 'Squash-merge the PR as soon as it's green. If your branch
has required CI checks or reviews, the merge waits for them.'

247/247 still pass.
Bumps [pnpm/action-setup](https://github.com/pnpm/action-setup) from 5 to 6.
- [Release notes](https://github.com/pnpm/action-setup/releases)
- [Commits](pnpm/action-setup@v5...v6)

---
updated-dependencies:
- dependency-name: pnpm/action-setup
  dependency-version: '6'
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot changed the title Bump pnpm/action-setup from 4 to 6 Bump pnpm/action-setup from 5 to 6 May 1, 2026
@dependabot dependabot Bot force-pushed the dependabot/github_actions/pnpm/action-setup-6 branch from 92c3114 to f90f90a Compare May 1, 2026 06:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file github_actions Pull requests that update GitHub Actions code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants