Skip to content

[Bug]: stale chat abort marker can suppress fresh chat events #91012

Description

@nxmxbbd

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

A retained chat abort marker for a reused chat run/idempotency key can suppress fresh chat delta/final events even when the new run was registered after the old abort marker.

Steps to reproduce

  1. On current main, seed chatRunState.abortedRuns with an abort marker for a chat client run id.
  2. Register a fresh chat run with the same client run id after that marker.
  3. Deliver an assistant delta followed by a lifecycle end event for the fresh run.
  4. Observe that the fresh run's chat delta/final projection is suppressed because the abort check only tests marker presence.

Expected behavior

A stale abort marker from an older run should not suppress chat events for a fresh run registered after that marker. A current abort marker for the active run should still suppress live chat projection.

Actual behavior

The stale marker suppresses the fresh run's chat projection, so no delta or final chat state is emitted for the fresh run.

OpenClaw version

upstream/main at caae4c91092dabc89d64001ad7aaf90ad019097a.

Operating system

Linux local checkout.

Install method

Local checkout using the repository test/runtime commands.

Model

N/A --- this repro exercises Gateway chat event projection state before any model/provider call is involved.

Provider / routing chain

N/A --- provider routing is not involved in the repro.

Additional provider/model setup details

N/A --- no provider/model call is required to reproduce this state bug.

Logs, screenshots, and evidence

Current-main RED proof added a regression covering the stale marker case and failed with no chat states emitted:

expected [] to have a length of 2 but got +0

The failing condition is the stale-marker presence check: the fresh run expected delta and final, but the old marker caused both to be suppressed.

Impact and severity

Affected: Gateway chat clients when a chat abort marker is retained longer than normal chat send dedupe and a fresh run reuses the same client run/idempotency key.

Severity: Medium. The active run can complete, but clients miss the fresh chat delta/final projection and can appear stuck or silent.

Frequency: Edge case, bounded by abort-marker retention and id/key reuse.

Consequence: Fresh successful chat output can be hidden from chat subscribers until another refresh/path recovers state.

Additional information

The abort marker TTL is longer than normal chat send dedupe. This makes stale marker retention possible after the original dedupe entry has expired. The fix should preserve current abort suppression while distinguishing markers older than the fresh chat run registration.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Normal backlog priority with limited blast radius.clawsweeper:linked-pr-openClawSweeper found an open linked pull request for this issue.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.impact:message-lossChannel message delivery can be lost, duplicated, or misrouted.impact:session-stateSession, memory, transcript, context, or agent state can drift or corrupt.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions