Repository navigation
release: carry #1212, #1218 and #1085 onto 0.6.11 - #1252
Conversation
…ough its staged script OPR.0.7.0.5. OpenRig types every Codex launch (fresh, fork, resume, and this restart's own relaunch) as `/bin/sh <tmpdir>/openrig-tmux-send-<pid>-<uuid>.txt`, so a managed Codex runs one sh below the pane's shell, and `rig seat restart --keep-conversation` refused it as pane_shape_unknown (the same chain on 0.6.10). The shell-backed shape now also accepts exactly that one link: an sh whose only argument is an absolute path with the name the tmux adapter gives its staged scripts (isStagedSendScriptPath). Any other process between the shell and Codex is still refused. The native harness gains a case that launches through the adapter's staging and restarts twice in the same pane (red on main). It also folds in #1196's fixture LOW: the direct-native case compares the stub with the reported replacement process and ties it to the respawned pane separately, so it holds where the image's sh doesn't exec a lone command. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> (cherry picked from commit e773e5b)
…ns as bash Found in review, measured on macOS: /bin/sh there is a shim that runs bash (or dash or zsh), so ps names the staged script's process bash and the new link never matched. The link now accepts the shells /bin/sh can run as (sh, bash, dash, zsh) for the process name, and keeps every argv check: exactly two arguments, argv[0] /bin/sh or sh, and the staged absolute path. A macOS-shaped fixture (bash, /bin/sh /var/folders/.../T/openrig-tmux-send-...) is accepted (red before this change); `/bin/bash <script>` and an extra argument stay refused. LOW: the staged script's name now comes from one prefix and suffix used by both the generator and the matcher, and a unit test passes the real defaultTmuxFileOps().tmpName() through the matcher. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> (cherry picked from commit df7ee77)
…nly a missing conversation A pod-aware resume rolled the seat back as unresumable whenever the runtime adapter answered retry_fresh. Claude's adapter gives that answer both when Claude reports the conversation doesn't exist and when the pane simply ends up back at its shell, so a Claude that exited for any other reason lost its pane, its error output with it, and was told its conversation was unresumable. The adapters now mark a retry_fresh failure that comes from the runtime's own missing-conversation report (Claude's "No conversation found", Codex's missing saved session, Pi's missing session file). The pod-aware restore rolls back only on that mark. A pane that returned to its shell for another reason is reported failed, with its session, pane and binding kept, as before the rollback existed. The hint's other readers (the fresh fallback, the in-place restart) are unchanged. Refs #1191 Claude-Session: https://claude.ai/code/session_01WfCu2MmcrSGRNX9Rjv1h6u (cherry picked from commit fae3e6e)
Claude's resume check reads the pane 16 times, then once more. The loop already marks Claude's "No conversation found" as a missing conversation, but the final read only checked resumed, attention and the shell, so a report that first appeared there came back unmarked and the pod-aware restore treated it as an ordinary failure. The final read now returns the same marked result before the shell check. Refs #1191 Claude-Session: https://claude.ai/code/session_01WfCu2MmcrSGRNX9Rjv1h6u (cherry picked from commit 0b9704e)
…d person with a pane (#1085) A registered person can also be a seat with its own pane. The destination resolver classes that address `pane-bound`, so `rig queue create --verify` reported only the terminal wake, even though the gateway may also post the row to that person in Slack. `GET /api/queue/:qitemId` now also returns `ownerNotificationLevel`, the level on the row's latest owner-notification transition (the one the Slack selector keys on), or null. When the terminal side applies and that level is set, or a gateway receipt already exists, `--verify` adds a `gateway` result: `posted`, a failure with its detail, or `still-pending` at the bound. The terminal side (`outcome`, `wakeResult`, `claim`) is reported as before, `humanReadership` stays unknown, and the wait keeps its 30 s default bound. "This is not a failed handoff" is no longer shown when Slack reports a failed delivery. A seat with no owner-notification level settles at once with no `gateway` field; gateway-routable destinations, registered aliases and `@external` keep the existing path; the create request, `--id` and `--no-nudge` are unchanged. With `output.compact` on, the short receipt keeps the whole `delivery` result, Slack side included. Refs #1029. (cherry picked from commit f07ddfe)
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Tests dispatched on head |
|
Tests on head |
openrig-review
left a comment
openrig-review
left a comment
There was a problem hiding this comment.
Approved at 0eeeff2, into release/0.6.11 (not main): the 0.6.11 candidate's three carried fixes, #1212 (two commits), #1218 (two commits) and #1085's own PR delta, as cherry-picks with their source lines, onto cb79b8c. Tree 0975a21e equals cb79b8c plus exactly the three deltas (19 files, their union); each commit's patch-id equals its source's. Tests run 38515269116 on this head: 7/8 on both attempts, package-tests (cli) failing a 0.05 s timeout race in chatroom.test.ts, a file unchanged since 0.6.10 and outside this delta; the same code passed 8/8, chatroom 54/54, in run 38516122112 on the stacked version-and-notes head. Read as indeterminate, not a regression; the exact-combination run on the release branch's final head settles it.
— dev60-planner@v-openrig-build
Brings the version and notes onto the release tip, after #1252 landed there by rebase. The capability page conflict keeps this branch's text; the tree is unchanged.
Version 0.6.10 to 0.6.11 in package.json, packages/{cli,daemon,ui}/package.json and package-lock.json; the 0.6.11 CHANGELOG section, whats-new note and capability page. Refs #1252.
Carries three already-reviewed fixes onto the 0.6.11 release branch, which starts at
cb79b8c9. Nothing else frommaincomes with them.Refs #1212
Refs #1218
Refs #1085
What is carried
Five commits, each made with
git cherry-pick -x, so each names the commit it came from:cb79b8c9..df7ee774(2 commits)76c25487,3f60aee22a3604b51927cb79b8c9..0b9704ec(2 commits)2b868a2d,1f0476262d45d3e82df1queue create --verifykeeps the Slack wait for a registered person with a panebf5d2b5f..f07ddfe3(its own change only)0eeeff2a9a51d7fa7fe3Each commit's own patch-id also equals its source commit's. The second commit's message is lightly reworded; its change is identical to the source's.
Nothing else came along
0975a21ee48ac67932ad70f5383c9b077bf5fae0.mainbetween its parent andcb79b8c9. The change still applies cleanly with the same patch-id, and ituses nothing that only appeared on
mainaftercb79b8c9.Merging
Please merge with a merge commit or a rebase, so the five commits keep their
cherry picked fromlines. A version and release-notes changefollows in a separate PR.
Tests
Release-branch PRs don't get the required checks attached automatically. Tests are dispatched on this branch's head; the run is linked
below.