State publishers thrash under concurrent writes

[vincentkoc]

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 18, 2026, 5:33 AM ET / 09:33 UTC.

Summary
Keep open for explicit maintainer scoping: this recent member-authored report names broad concurrent publisher contention, while the only concrete related material covers a narrower exact-publication starvation path that is already closed.

Reproducibility: no. The issue provides no steps, affected publisher paths, or observed current-main failure; the linked material only demonstrates a narrower exact-publication starvation scenario.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Next step
A maintainer should first establish whether a concrete publisher-contention defect remains outside the already-closed exact-publication scenario.

Maintainer decision needed

• Question: Does this issue describe a remaining publisher-contention bug beyond the exact-review publication starvation already covered by bug(queue): exact-review results remain unpublished behind broad state publishers #606, and if so, which publisher paths and expected behavior are in scope?
• Rationale: The title is broader than the concrete related report, and the empty body does not establish a reproducible remaining defect or a safe implementation boundary.
• Likely owner: vincentkoc — The member-authored report needs the reporter's intended operational scope and expected behavior before maintainer triage can safely narrow it.
• Options:
  • Request a bounded reproduction (recommended): Ask for the contending publisher paths, an observable failure, and current-main evidence before opening a new repair path.
  • Treat it as the resolved narrow case: If the intended report was only the exact-publication starvation scenario, close it as covered by the resolved related work.

Review details

Best possible solution:

Define one current-main reproduction that identifies the competing publisher paths, expected publication latency or ordering, and the durable state that must remain correct; then compare that path against the existing exact-publication protections before selecting a narrow repair.

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

No. The issue provides no steps, affected publisher paths, or observed current-main failure; the linked material only demonstrates a narrower exact-publication starvation scenario.

Is this the best way to solve the issue?

Unclear. A queue or publisher change is not yet the best proven solution because the report does not distinguish its intended contention path from the related closed work.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Closing would discard a broad concurrency concern without evidence that current main covers every affected publisher path.
• Dispatching a repair before the scope is defined risks duplicating the already-closed exact-publication work or changing unrelated queue serialization.

Codex review notes: model internal, reasoning high; reviewed against 18bd4ce946db.

Label changes

Label changes:

• add issue-rating: 🦪 silver shellfish: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.
• remove issue-rating: 🦐 gold shrimp: Current issue advisory state no longer selects this label.

Label justifications:

• P1: If confirmed, concurrent publisher contention can delay durable review publication and disrupt an active review workflow, but the remaining scope is not yet reproducible.
• impact:other: The reported effect is operational review-publication contention rather than a specifically evidenced data-loss, security, message-delivery, session-state, or provider problem.

Evidence reviewed

What I checked:

• Current report lacks a defined failure boundary: The issue body is empty, and the prior completed review found that the available material did not establish which publisher paths, symptoms, or contention scenario remain affected on current main.
• Related report is narrower: The linked closed issue bug(queue): exact-review results remain unpublished behind broad state publishers #606 explicitly distinguishes its exact-review publication starvation scenario from this broader report and says this issue does not describe that single-slot failure path.
• Related proposed fix was not merged: The linked pull request fix(queue): prevent expired publications from starving later results #607 was closed unmerged and addressed expired exact-publication lease fairness, so it cannot prove that all concurrent state-publisher contention described here is resolved.

Likely related people:

• vincentkoc: The report is member-authored and currently has no body, so this person is the best available source for defining the intended contention scenario and expected observable behavior. (role: issue author and likely scope owner; confidence: medium)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[brokemac79]

@clawsweeper re-review

[clawsweeper]

🦞🧹
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: Complete
• Detail: The durable review comment was published and its verdict was queued for target-serialized routing.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/29639392773
• Updated: 2026-07-18T09:37:49.218Z

[clawsweeper]

ClawSweeper status: review started.

I am starting a fresh review of this issue: State publishers thrash under concurrent writes This is item 1/1 in the current shard. Shard 0/1.

This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking.

Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted.