fix(lobster): don't route schema-default flowExpectedRevision into TaskFlow (#102011)#102022
Conversation
|
Codex review: needs maintainer review before merge. Reviewed July 8, 2026, 1:39 AM ET / 05:39 UTC. Summary PR surface: Source +3, Tests +90. Total +93 across 2 files. Reproducibility: yes. source-level. Current main and Review metrics: 1 noteworthy metric.
Stored data model Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Land one focused Lobster parser fix, with this PR as a clean candidate, then close the canonical issue and duplicate candidate PRs after the merge. Do we have a high-confidence way to reproduce the issue? Yes, source-level. Current main and Is this the best way to solve the issue? Yes. A plugin-local parser fix is the narrowest maintainable solution because docs and runtime already define ordinary and managed modes, and no core API or Lobster runtime change is needed. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against ee6c576e8fd5. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Source +3, Tests +90. Total +93 across 2 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
Review history (3 earlier review cycles)
|
clawsweeper
Bot
added
rating: 🦪 silver shellfish
863643b to
987309a
Compare
|
Addressed the review:
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. |
clawsweeper
Bot
added
proof: sufficient
…penclaw#102011) Ordinary lobster run/resume calls were misrouted into managed TaskFlow mode when the tool schema injected default flow fields (e.g. flowExpectedRevision=0, an empty flowStateJson): resume failed with "flowId required when using managed TaskFlow resume mode" and run with "flowControllerId required..." / "run action does not accept flowId or flowExpectedRevision". Managed mode is identified only by its intentional flow identifiers — flowId for resume, flowControllerId/flowGoal for run. Secondary fields (flowExpectedRevision, flowStateJson, step fields) that the schema can inject as defaults no longer select managed mode. Real managed flows are unchanged (managed resume still requires flowExpectedRevision; managed run still needs flowControllerId/flowGoal). Co-Authored-By: Claude Fable 5 <[email protected]>
987309a to
4ab0876
Compare
clawsweeper
Bot
removed
proof: sufficient
|
Addressed the re-review finding (P2):
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. |
clawsweeper
Bot
added
proof: sufficient
|
Closing as superseded by #102036, merged in 8cb9263. The canonical fix includes the valid schema-default routing insight from this PR, and also handles blank/empty flow state, preserves explicit managed |
2 participants
Closes #102011
What Problem This Solves
Fixes an issue where ordinary
@openclaw/lobstertoolrun/resumecallsfail by being misrouted into managed TaskFlow mode. When the tool schema supplies
default flow fields for a minimal call —
flowExpectedRevision(e.g.0) or anempty
flowStateJson— the wrapper treated those always-present values as amanaged-flow signal, so an ordinary
resumeerrored withflowId required when using managed TaskFlow resume modeand an ordinaryrunwithflowControllerId required when using managed TaskFlow run mode/run action does not accept flowId or flowExpectedRevision. The standalone Lobster CLI handled the sameworkflow correctly, confirming the fault is in the OpenClaw plugin wrapper.
Why This Change Was Made
Managed TaskFlow mode is identified only by its intentional flow identifiers —
flowIdforresume,flowControllerId/flowGoalforrun. Secondary fields(
flowExpectedRevision,flowStateJson, and the step fields), which the toolschema can inject as defaults, no longer select managed mode on their own. Real
managed flows are unchanged: managed
resumestill requiresflowExpectedRevision, and managedrunstill needsflowControllerId/flowGoal.User Impact
The documented minimal
run/resumeLobster tool calls work again; ordinaryapproval workflows no longer fail with a spurious managed-TaskFlow error.
Evidence
Real behavior proof — drove the actual
createLobsterToolwith the realembedded
@clawdbot/lobsterruntime executing the issue'sapproval-smokeworkflow, passing the schema-injected defaults (
flowExpectedRevision: 0,flowStateJson: "{}") on the minimalrun, thenresumewith the returnedtoken:
(Ran via a temporary
*.test.tsusingcreateEmbeddedLobsterRunner(); capturedthe before/after by toggling the source with
git stash. Not committed.)Regression tests in
extensions/lobster/src/lobster-tool.test.ts(colocated,run the real
createLobsterTool):resumecarrying only a schema-defaultflowExpectedRevisionruns asan ordinary resume instead of erroring;
runcarrying only a schema-defaultflowStateJsonruns as anordinary run instead of erroring;
runwith an injectedflowExpectedRevision: 0is still accepted.Full suite passes (20 tests) via
node scripts/run-vitest.mjs run extensions/lobster/src/lobster-tool.test.ts. oxfmt/oxlint clean.AI-assisted: written with Claude Code. The before/after evidence is from running
the real lobster runtime locally, not AI-generated assertions taken on faith.