fix(agents): prioritize manual session turns by galiniliev · Pull Request #82765 · openclaw/openclaw

galiniliev · 2026-05-16T22:29:19Z

Summary

Problem: manual user follow-ups and background cron/maintenance turns used the same FIFO session lane, so a visible follow-up could wait behind already queued background work during compaction.
Why it matters: the Control UI can look stuck or lost while cron/compaction work continues to take turns in the same session.
What changed: command queue entries now carry foreground/normal/background priority while preserving FIFO order within each priority; embedded user/manual session runs enqueue as foreground and cron/heartbeat/memory/overflow runs enqueue as background.
What did NOT change (scope boundary): active runs are not preempted, global lane ordering is unchanged, and this does not add UI queue-owner labeling.

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Closes [Bug]: manual follow-up can queue behind cron compaction work #82764
Related #
This PR fixes a bug or regression

Real behavior proof (required for external PRs)

Behavior addressed: Manual/user embedded turns are selected ahead of already queued cron/maintenance turns in the same session lane once the active turn releases the lane.
Real environment tested: Azure Crabbox Linux lease swift-hermit / cbx_92ae6d7312ee, remote workdir /work/crabbox/cbx_92ae6d7312ee/openclaw-pr-82765, evidence head 501421bdfacc41b46150b2844a6b770552ebee29; current prepared head e0d4f2b4b792772cc29adbd67a236799047d8930 is a rebase/changelog refresh with the focused regression tests rerun locally. Fix code path unchanged except rebase SHA.
Exact steps or command run after this patch: /home/galini/.codex/skills/crabbox-oc-evidence/scripts/collect-openclaw-evidence.sh --id swift-hermit --name pr-82765-manual-session-priority-rerun --skip-bootstrap --skip-install --test src/process/command-queue.test.ts --test src/agents/pi-embedded-runner/run.overflow-compaction.test.ts --command <queue-priority-probe>
Evidence after fix: Console output copied from the Azure Crabbox after-fix run:

CRABBOX_PHASE:tests
src/process/command-queue.test.ts: 28 tests passed
src/agents/pi-embedded-runner/run.overflow-compaction.test.ts: 24 tests passed
CRABBOX_PHASE:evidence_1
AFTER_FIX_QUEUE_PRIORITY_PROOF=foreground>normal>background
AFTER_FIX_QUEUE_RESULT_PROOF=blocker>foreground>normal>background
run summary provider=azure leaseId=cbx_92ae6d7312ee slug=swift-hermit exitCode=0 sync=7.162s command=43.179s total=50.408s

Observed result after fix: The copied console output shows one active session-lane blocker completing first, then queued work draining in priority order after release: foreground first, normal second, background last. The focused embedded-run regression also verified user-triggered session work is marked foreground and cron-triggered session work is marked background.
What was not tested: A live Control UI/gateway plus scheduled cron repro was not rerun; this proof exercises the changed queue/runtime seam and focused regression tests on the PR head.
Before evidence (optional but encouraged): Redacted local evidence in #82764 and the raw gateway logs proves the ordering/timing:

UI showed the manual follow-up as Queued (1) while the same session showed Compacting context....
Session trace line 1148 recorded [assistant turn failed before producing content] with an over-context error; line 1149 immediately recorded compaction.
Session trace lines 1160-1162 showed hidden sessions_yield progress with display=false.
Session trace line 1171 recorded a scheduled review-poll/cron message arriving immediately after the review synthesis window.
gateway-dev-1.log:34179 recorded message queued ... source=pi-embedded-runner queueDepth=2 sessionState=processing.
gateway-dev-1.log:34189 recorded the active run completing with queueDepth=1; gateway-dev-1.log:34204 recorded a new run starting with queueDepth=1.
gateway-dev-1.log:34196 recorded lane wait exceeded ... waitedMs=20967 queueAhead=1; gateway-dev-1.log:34235 recorded lane wait exceeded ... waitedMs=35984 queueAhead=0.
gateway-dev-1.log:34334 recorded compactionSummary:1; gateway-dev-1.log:34411 and gateway-dev-1.log:34417 recorded the later drain to queueDepth=0 and lane queued=0.

This establishes the before-fix behavior: a human-visible same-session follow-up could be queued during compaction while background/session work still occupied the lane, then the queue eventually drained, making the UI state misleading rather than permanently stuck.

Root Cause (if applicable)

Root cause: session-lane work was FIFO and did not carry source priority, so background cron/maintenance turns could remain ahead of later manual user follow-ups for the same session.
Missing detection / guardrail: no regression covered foreground-vs-background queue ordering or embedded-run trigger priority mapping.
Contributing context (if known): compaction and hidden sessions_yield progress made the visible UI state look idle/stuck while queued work continued internally.

Regression Test Plan (if applicable)

Coverage level that should have caught this:
- Unit test
- Seam / integration test
- End-to-end test
- Existing coverage already sufficient
Target test or file: src/process/command-queue.test.ts; src/agents/pi-embedded-runner/run.overflow-compaction.test.ts
Scenario the test should lock in: foreground work runs before already queued background work while preserving FIFO within a priority; user-triggered embedded runs mark session queue work as foreground and cron-triggered runs mark it as background.
Why this is the smallest reliable guardrail: the bug is in session lane selection and embedded run trigger classification, before provider generation or channel delivery.
Existing test that already covers this (if any): None found.
If no new test is added, why not: N/A

User-visible / Behavior Changes

Manual/user follow-ups in a session are favored over background cron/maintenance turns that are queued but not yet active on the same session lane.

Diagram (if applicable)

Before:
[active session turn] -> [cron queued] -> [manual follow-up queued] -> cron runs first

After:
[active session turn] -> [cron background queued] -> [manual foreground queued] -> manual runs first

Security Impact (required)

New permissions/capabilities? (Yes/No) No
Secrets/tokens handling changed? (Yes/No) No
New/changed network calls? (Yes/No) No
Command/tool execution surface changed? (Yes/No) No
Data access scope changed? (Yes/No) No
If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

OS: Windows worktree for source edits; original observed OS was not grounded.
Runtime/container: Node/pnpm worktree; local dependency postinstall was blocked.
Model/provider: NOT_ENOUGH_INFO
Integration/channel (if any): Control UI session with scheduled review/cron work.
Relevant config (redacted): Same-session manual follow-up during compaction while a scheduled review-poll turn targets the session.

Steps

Run a long visible session turn until over-context compaction starts.
Submit a manual follow-up in the same Control UI session.
Let a background scheduled review/cron turn target the same session before the manual follow-up is serviced.

Expected

Queued manual/user work should be selected before queued background cron/maintenance work in the same session lane.

Actual

Before this patch, the session lane was FIFO, so queued background work could stay ahead of the manual follow-up.

Evidence

Attach at least one:

Failing test/log before + passing after
Trace/log snippets
Screenshot/recording
Perf numbers (if relevant)

Stronger redacted log proof

The original incident is backed by both the session trace summary and raw gateway queue diagnostics. This is a before-fix proof of the reported behavior; it shows a real same-session queue ordering problem, not a permanent hang.

Step	Evidence	What it proves
1	UI screenshot evidence: the manual follow-up was shown as `Queued (1)` while the same session showed `Compacting context...`	A human-visible follow-up was waiting during compaction
2	Session trace line 1148 recorded `[assistant turn failed before producing content]` with an over-context error; line 1149 immediately recorded a compaction entry	Compaction began immediately after the over-context failure
3	Session trace lines 1160-1162 showed `sessions_yield` progress with `display=false`	Progress continued but was hidden from the visible chat
4	Session trace line 1171 recorded a scheduled review-poll/cron message arriving immediately after the review synthesis window; line 1179 recorded the scheduled report including the same reviewed item	Background scheduled work entered the same session window before the visible follow-up had clearly drained
5	`gateway-dev-1.log:34179`: `message queued ... source=pi-embedded-runner queueDepth=2 sessionState=processing`	Two pending items existed while the affected session was already processing
6	`gateway-dev-1.log:34189`: `run_completed queueDepth=1`; `gateway-dev-1.log:34204`: `run_started queueDepth=1`	One queued item remained after the active run completed, and another run began before the queue reached zero
7	`gateway-dev-1.log:34196`: `lane wait exceeded ... waitedMs=20967 queueAhead=1`; `gateway-dev-1.log:34235`: `lane wait exceeded ... waitedMs=35984 queueAhead=0`	The wait was real lane contention, first with one queued item still ahead and then with the lane active but no queued item ahead
8	`gateway-dev-1.log:34334`: pre-prompt context diagnostic included `compactionSummary:1`; `gateway-dev-1.log:34411` and `gateway-dev-1.log:34417`: `queueDepth=0` and lane `queued=0`	The session had compacted context, then eventually drained; the defect is misleading foreground/background ordering and UI state, not permanent stuckness

Redactions applied: exact session key, run/session ids, local session file path, private reviewed item URL, and setup-specific scheduled job name.

Human Verification (required)

What you personally verified (not just CI), and how:

Verified scenarios: Manual diff review; git diff --check passed.
Edge cases checked: FIFO preservation within equal priority; legacy in-process queue state missing priority/sequence fields gets normalized before new priority comparisons.
What you did not verify: Focused Vitest, live Control UI behavior, or Crabbox/Testbox proof due the environment/tooling blockers listed above.

Review Conversations

I replied to or resolved every bot review conversation I addressed in this PR.
I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

Backward compatible? (Yes/No) Yes
Config/env changes? (Yes/No) No
Migration needed? (Yes/No) No
If yes, exact upgrade steps: N/A

Risks and Mitigations

Risk: Priority ordering could starve background work if foreground follow-ups keep arriving.
- Mitigation: The priority only affects queued, not active, work within the session lane; FIFO is preserved within each priority, and background work still runs once foreground turns drain.

clawsweeper · 2026-05-16T22:30:11Z

Codex review: needs maintainer review before merge.

Summary
Adds priority-aware command queue entries, maps embedded manual/user session runs to foreground and cron/heartbeat/memory/overflow runs to background, and adds focused tests plus a changelog entry.

Reproducibility: yes. source-level: current main queues same-lane entries FIFO and the linked issue provides redacted queue logs showing a manual follow-up waiting while background/session work occupied the lane. I did not rerun the full live Control UI plus cron scenario.

Real behavior proof
Sufficient (live_output): The PR includes after-fix Azure Crabbox live output showing focused tests passing and the queue probe draining foreground before normal and background work.

Next step before merge
Protected maintainer label and the foreground/background scheduler fairness policy need human approval; there is no narrow automated repair because review found no blocking patch defect and proof is sufficient.

Security
Cleared: The diff changes only in-process queue scheduling, focused tests, and changelog text; it adds no dependency, permission, secret, network, CI, package, or command execution surface.

Review details

Best possible solution:

Land this PR or an equivalent internal scheduler change after maintainer approval, preserving active-run non-preemption and FIFO within priority.

Do we have a high-confidence way to reproduce the issue?

Yes, source-level: current main queues same-lane entries FIFO and the linked issue provides redacted queue logs showing a manual follow-up waiting while background/session work occupied the lane. I did not rerun the full live Control UI plus cron scenario.

Is this the best way to solve the issue?

Likely yes: centralizing priority selection in src/process/command-queue.ts and mapping embedded-run triggers in src/agents/pi-embedded-runner/run.ts is the narrow maintainable fix. The remaining question is maintainer-approved scheduling policy, not a concrete code defect in the patch.

Acceptance criteria:

node scripts/run-vitest.mjs src/process/command-queue.test.ts src/agents/pi-embedded-runner/run.overflow-compaction.test.ts
Optional Crabbox/Testbox live Control UI plus scheduled cron proof if maintainers want end-to-end confirmation

What I checked:

Current main FIFO queue: Current main enqueues lane work with state.queue.push(...) and drains it with shift(), so same-lane entries are selected FIFO without source priority. (src/process/command-queue.ts:365, e98ebb5739c4)
Current embedded session enqueue lacks trigger priority: Current main resolves a session lane and forwards session enqueue options without classifying manual/user triggers separately from cron/background triggers. (src/agents/pi-embedded-runner/run.ts:398, e98ebb5739c4)
Trigger contract is bounded: The embedded run trigger type is a closed union of cron, heartbeat, manual, memory, overflow, and user, which matches the PR's priority mapping surface. (src/agents/pi-embedded-runner/run/params.ts:31, e98ebb5739c4)
PR queue implementation: The PR diff adds queue entry sequence and priority, inserts queued entries by priority while preserving sequence order, and extends queue tests for foreground-before-background plus FIFO within priority. (src/process/command-queue.ts:228, 2bc5e9ed5a25)
PR embedded trigger mapping: The PR maps user and manual to foreground, and cron, heartbeat, memory, and overflow to background before session enqueue. (src/agents/pi-embedded-runner/run.ts:211, 2bc5e9ed5a25)
Real behavior proof: The PR body/comment include after-fix Azure Crabbox live output showing focused tests passing and a queue probe draining blocker>foreground>normal>background; API inspection showed the proofed code patch matches the current code commit and the latest head only adds the changelog entry. (e0d4f2b4b792)

Likely related people:

@steipete: Recent path history shows repeated work on both src/process/command-queue.ts and src/agents/pi-embedded-runner/run.ts, including lane timeout and session/runtime changes adjacent to this scheduler behavior. (role: recent area contributor; confidence: high; commits: 21c5f8dc6df1, 41859bb3fc93, 07f05e972e27; files: src/process/command-queue.ts, src/agents/pi-embedded-runner/run.ts)
@vincentkoc: Recent history includes command-queue restart-drain work and embedded-run media/runtime changes, making this a plausible routing candidate for queue correctness review. (role: adjacent queue/runtime contributor; confidence: medium; commits: ec1f72b6c58f, 310c8530eb81; files: src/process/command-queue.ts, src/agents/pi-embedded-runner/run.ts)
@MertBasar0: Recent command-queue history includes state-aware failover and lane suspension changes, which are close to the lane ordering and scheduling surface touched here. (role: adjacent lane-suspension contributor; confidence: medium; commits: 029ca8c26884; files: src/process/command-queue.ts)

Remaining risk / open question:

Sustained foreground traffic can delay background work; the PR preserves FIFO within each priority, but the fairness policy needs maintainer approval.
The proof exercises the queue/runtime seam and focused tests, not a live Control UI plus scheduled cron repro.

Codex review notes: model gpt-5.5, reasoning high; reviewed against e98ebb5739c4.

galiniliev · 2026-05-16T22:49:28Z

Stronger redacted log proof

The original incident is backed by both the session trace summary and raw gateway queue diagnostics. This is a before-fix proof of the reported behavior; it shows a real same-session queue ordering problem, not a permanent hang.

Step	Evidence	What it proves
1	UI screenshot evidence: the manual follow-up was shown as `Queued (1)` while the same session showed `Compacting context...`	A human-visible follow-up was waiting during compaction
2	Session trace line 1148 recorded `[assistant turn failed before producing content]` with an over-context error; line 1149 immediately recorded a compaction entry	Compaction began immediately after the over-context failure
3	Session trace lines 1160-1162 showed `sessions_yield` progress with `display=false`	Progress continued but was hidden from the visible chat
4	Session trace line 1171 recorded a scheduled review-poll/cron message arriving immediately after the review synthesis window; line 1179 recorded the scheduled report including the same reviewed item	Background scheduled work entered the same session window before the visible follow-up had clearly drained
5	`gateway-dev-1.log:34179`: `message queued ... source=pi-embedded-runner queueDepth=2 sessionState=processing`	Two pending items existed while the affected session was already processing
6	`gateway-dev-1.log:34189`: `run_completed queueDepth=1`; `gateway-dev-1.log:34204`: `run_started queueDepth=1`	One queued item remained after the active run completed, and another run began before the queue reached zero
7	`gateway-dev-1.log:34196`: `lane wait exceeded ... waitedMs=20967 queueAhead=1`; `gateway-dev-1.log:34235`: `lane wait exceeded ... waitedMs=35984 queueAhead=0`	The wait was real lane contention, first with one queued item still ahead and then with the lane active but no queued item ahead
8	`gateway-dev-1.log:34334`: pre-prompt context diagnostic included `compactionSummary:1`; `gateway-dev-1.log:34411` and `gateway-dev-1.log:34417`: `queueDepth=0` and lane `queued=0`	The session had compacted context, then eventually drained; the defect is misleading foreground/background ordering and UI state, not permanent stuckness

Redactions applied: exact session key, run/session ids, local session file path, private reviewed item URL, and setup-specific scheduled job name.

galiniliev · 2026-05-16T23:39:59Z

@clawsweeper re-review

Prepared the proof gate after adding the Azure Crabbox evidence to the PR body.

Behavior addressed: manual/user embedded session work is selected ahead of queued cron/background work once the active session-lane task releases.
Real environment tested: Azure Crabbox, provider azure, slug swift-hermit, lease cbx_92ae6d7312ee, remote workdir /work/crabbox/cbx_92ae6d7312ee/openclaw-pr-82765, PR head 501421bdfacc41b46150b2844a6b770552ebee29.
Exact command run after this patch: /home/galini/.codex/skills/crabbox-oc-evidence/scripts/collect-openclaw-evidence.sh --id swift-hermit --name pr-82765-manual-session-priority-rerun --skip-bootstrap --skip-install --test src/process/command-queue.test.ts --test src/agents/pi-embedded-runner/run.overflow-compaction.test.ts --command <queue-priority-probe>
Evidence after fix:

src/process/command-queue.test.ts: 28 tests passed
src/agents/pi-embedded-runner/run.overflow-compaction.test.ts: 24 tests passed
AFTER_FIX_QUEUE_PRIORITY_PROOF=foreground>normal>background
AFTER_FIX_QUEUE_RESULT_PROOF=blocker>foreground>normal>background
run summary provider=azure leaseId=cbx_92ae6d7312ee slug=swift-hermit exitCode=0 sync=7.162s command=43.179s total=50.408s

Observed result after fix: with one active session-lane blocker, queued foreground work ran before normal and background work after release. The focused embedded-run test also verifies user-triggered session work is marked foreground and cron-triggered session work is marked background.
What was not tested: live Control UI/gateway plus scheduled cron repro; this proof exercises the changed queue/runtime seam on the PR head.

Latest proof gate: Real behavior proof run 25975977185, job 76356055240, passed.

clawsweeper · 2026-05-16T23:41:28Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

State: Failed
Detail: The targeted re-review did not finish cleanly. Check the workflow run for details.
Run: https://github.com/openclaw/clawsweeper/actions/runs/25976021166
Updated: 2026-05-16T23:43:19.163Z

galiniliev · 2026-05-17T00:49:29Z

Pre-merge verification for current head e0d4f2b4b792772cc29adbd67a236799047d8930:

GitHub checks: 98 successful, 20 skipped, 0 pending, 0 failed; merge state CLEAN / MERGEABLE.
Local diff sanity: git diff --check upstream/main...HEAD passed after rebasing onto e98ebb5739c4eaa62a7cf6ad0fb36acd4fa8cdf0.
Focused regression proof: node scripts/run-vitest.mjs src/process/command-queue.test.ts src/agents/pi-embedded-runner/run.overflow-compaction.test.ts passed with 3 files / 76 tests.
Real behavior proof policy: node scripts/github/real-behavior-proof-policy.mjs --body-file /tmp/pr82765-body-land.md passed.
Azure Crabbox evidence: provider azure, slug swift-hermit, lease cbx_92ae6d7312ee, evidence head 501421bdfacc41b46150b2844a6b770552ebee29; focused tests passed and queue probe showed AFTER_FIX_QUEUE_PRIORITY_PROOF=foreground>normal>background plus AFTER_FIX_QUEUE_RESULT_PROOF=blocker>foreground>normal>background.

Known proof gap: live Control UI/gateway plus scheduled cron repro was not rerun; verification covers the changed queue/runtime seam, PR checks, focused tests, and the after-fix queue ordering proof.

* fix(gateway): clear CLI bindings on session reset * fix(gateway): preserve spawned sessions in configured lists * fix(channels): clear canonical stale routes * fix(telegram): preserve forum topic origin targets * fix(agents): skip fallback for session coordination errors * fix(agents): persist subagent registry before returning accepted (openclaw#83132) (openclaw#83238) * fix(memory): catch up stale sessions on startup (openclaw#82341) * fix(memory): preserve qmd lexical search for hyphenated queries (openclaw#81423) * fix(anthropic): preserve Claude image capability (openclaw#83756) * fix(agents): exclude tool result details from guard budget (openclaw#75525) * fix(provider): use Together video API endpoint * fix(telegram): preserve implicit default account (openclaw#82794) * fix(gateway): allow trusted-proxy local-direct password fallback (openclaw#82953) * fix(discord): return subagent thread delivery origin * fix: add missing prerequisites for upstream-ported fixes Add SessionWriteLockTimeoutError class and hasSessionWriteLockTimeout helper needed by the ported fix(agents) skip-fallback commit. Remove route property references from session-delivery.ts that don't exist in gemmaclaw's SessionEntry type. Add authorizePasswordAuth helper that was present in upstream but missing from gemmaclaw's auth.ts. * fix: remove route assertions incompatible with gemmaclaw SessionEntry Remove test assertions using .route property that exists in upstream's SessionEntry type but not in gemmaclaw's, restoring typecheck green. * fix(memory-core): yield event loop during fallback vector search (openclaw#81172) (openclaw#83758) Summary: - The branch changes memory-core fallback vector search to scan chunks in 256-row rowid batches with `setImmediate` yields, updates regression tests, and adds a changelog entry. - Reproducibility: yes. from source and supplied live output. Current main synchronously scans fallback vector ... and the PR body shows the before/after heartbeat behavior through the actual `searchVector` fallback path. Automerge notes: - PR branch already contained follow-up commit before automerge: test(memory-core): add boundary, parity, and concurrent-insert covera… - PR branch already contained follow-up commit before automerge: fix(memory-core): yield event loop during fallback vector search (#81… Validation: - ClawSweeper review passed for head 0ede3d7. - Required merge gates passed before the squash merge. Prepared head SHA: 0ede3d7 Review: openclaw#83758 (comment) Co-authored-by: NW <nitinwadhawan66@gmail.com> Co-authored-by: clawsweeper <274271284+clawsweeper[bot]@users.noreply.github.com> Co-authored-by: clawsweeper[bot] <274271284+clawsweeper[bot]@users.noreply.github.com> Approved-by: takhoffman Co-authored-by: takhoffman <781889+takhoffman@users.noreply.github.com> * fix(subagents): collect unresolved announce batches (openclaw#83701) Summary: - The PR changes collect-mode follow-up queue routing so unresolved-origin items can batch with a single resolved route and later compatible items can resume batching after a true cross-channel drain. - Reproducibility: yes. at source level: current main treats unkeyed-plus-same-keyed queue items as cross-chan ... failing path is directly visible in `src/utils/queue-helpers.ts` and `src/auto-reply/reply/queue/drain.ts`. Automerge notes: - PR branch already contained follow-up commit before automerge: Merge remote-tracking branch 'origin/main' into maint-83701-20260518 Validation: - ClawSweeper review passed for head e6ad029. - Required merge gates passed before the squash merge. Prepared head SHA: e6ad029 Review: openclaw#83701 (comment) Co-authored-by: Andy Ye <35905412+TurboTheTurtle@users.noreply.github.com> Co-authored-by: clawsweeper[bot] <274271284+clawsweeper[bot]@users.noreply.github.com> Approved-by: takhoffman Co-authored-by: takhoffman <781889+takhoffman@users.noreply.github.com> * fix(config): accept gateway remote port * fix: restore Array<{}> closing bracket in manager-search.ts Cherry-pick 68b3729 accidentally dropped the '>' from '}>', producing a syntax error. Restore '}>;' as it was in origin/main. * fix: add remotePort to GatewayRemoteConfig and GatewayRemoteConfigSchema * fix(agents): prioritize manual session turns (openclaw#82765) * fix(agents): prioritize manual session turns * docs: update changelog for session priority --------- Co-authored-by: Galin Iliev <Galin.Iliev@microsoft.com> * revert: fix(agents): prioritize manual session turns (openclaw#82765) - upstream deps not in gemmaclaw * fix: resolve undefined variable errors in cherry-picked extension code * fix(tui): preserve draft while chat is busy * fix(tui): add pendingChatRunId to TuiStateAccess for cherry-picked tui commit * fix(memory-wiki): make wiki_lint tool output path-safe (openclaw#83687) * fix(ui): render session-scoped tool events (openclaw#83734) * chore: regenerate base config schema after upstream cherry-picks * fix(agents): add persistSubagentRunsToDiskOrThrow to subagent-registry test mock New export added to subagent-registry-state.ts was missing from the vi.mock definition, causing all tests in the suite to skip and the module to fail to load. * fix(telegram): wire buildTelegramInboundOriginTarget into session context Cherry-pick 675e053 added the helper and the test assertion but did not update bot-message-context.session.ts to use it. OriginatingTo now correctly includes :topic:<id> for forum groups. * fix(memory): correct session path format in startup-catchup test sessionPathForFile returns sessions/<basename> (no agent dir), but the cherry-picked test used sessions/main/<basename>. The clean-file test always failed because the path mismatch made every file look unindexed. * fix(together): update video generation test URL from v1 to v2 The source uses TOGETHER_VIDEO_BASE_URL = https://api.together.xyz/v2 but the cherry-picked test still asserted the old v1 URL. --------- Co-authored-by: nitinjwadhawan <nitinwadhawan66@gmail.com> Co-authored-by: clawsweeper <274271284+clawsweeper[bot]@users.noreply.github.com> Co-authored-by: takhoffman <781889+takhoffman@users.noreply.github.com> Co-authored-by: Andy Ye <35905412+TurboTheTurtle@users.noreply.github.com> Co-authored-by: Peter Steinberger <steipete@gmail.com> Co-authored-by: Galin Iliev <iliev@galcho.com> Co-authored-by: Galin Iliev <Galin.Iliev@microsoft.com> Co-authored-by: Harry Xie <harryhsieh963@yahoo.com>

* fix(agents): prioritize manual session turns * docs: update changelog for session priority --------- Co-authored-by: Galin Iliev <Galin.Iliev@microsoft.com>

openclaw-barnacle Bot added agents Agent runtime and tooling size: S maintainer Maintainer-authored PR labels May 16, 2026

clawsweeper Bot mentioned this pull request May 16, 2026

[Bug]: manual follow-up can queue behind cron compaction work #82764

Closed

clawsweeper Bot added the P2 Normal backlog priority with limited blast radius. label May 16, 2026

clawsweeper Bot added the proof: sufficient ClawSweeper judged the real behavior proof convincing. label May 16, 2026

galiniliev force-pushed the bug-015-manual-follow-up-priority branch 2 times, most recently from 1efa62a to cc80630 Compare May 16, 2026 23:51

galiniliev and others added 2 commits May 17, 2026 00:40

fix(agents): prioritize manual session turns

2bc5e9e

docs: update changelog for session priority

e0d4f2b

galiniliev force-pushed the bug-015-manual-follow-up-priority branch from cc80630 to e0d4f2b Compare May 17, 2026 00:40

galiniliev merged commit 7c151b2 into openclaw:main May 17, 2026
119 checks passed

github-actions Bot mentioned this pull request May 17, 2026

📡 Upstream Digest — 2026-05-17 02:15 UTC curtismercier/openclaw-mods#877

Open

SebTardif mentioned this pull request May 17, 2026

feat(process): add starvation guard to priority command queue #75299

Open

SebTardif mentioned this pull request Jun 4, 2026

Command queue has no priority support; latency-sensitive work blocked by background tasks #79589

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(agents): prioritize manual session turns#82765

fix(agents): prioritize manual session turns#82765
galiniliev merged 2 commits into
openclaw:mainfrom
galiniliev:bug-015-manual-follow-up-priority

galiniliev commented May 16, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented May 16, 2026 •

edited

Loading

Uh oh!

galiniliev commented May 16, 2026

Uh oh!

galiniliev commented May 16, 2026

Uh oh!

clawsweeper Bot commented May 16, 2026 •

edited

Loading

Uh oh!

galiniliev commented May 17, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

galiniliev commented May 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Real behavior proof (required for external PRs)

Root Cause (if applicable)

Regression Test Plan (if applicable)

User-visible / Behavior Changes

Diagram (if applicable)

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual

Evidence

Stronger redacted log proof

Human Verification (required)

Review Conversations

Compatibility / Migration

Risks and Mitigations

Uh oh!

clawsweeper Bot commented May 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

galiniliev commented May 16, 2026

Stronger redacted log proof

Uh oh!

galiniliev commented May 16, 2026

Uh oh!

clawsweeper Bot commented May 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

galiniliev commented May 17, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

galiniliev commented May 16, 2026 •

edited

Loading

clawsweeper Bot commented May 16, 2026 •

edited

Loading

clawsweeper Bot commented May 16, 2026 •

edited

Loading