Summary

• Preserve Thread Ownership 409 ownership-conflict cancellation when the forwarder conflict body is oversized or malformed.
• Keep the 64 KiB bounded conflict-body read and log unreadable conflict bodies with owner reported as unknown.
• Keep the Slack mention bypass cache capped at 2000 entries, evicting the oldest remembered thread under high-cardinality mention traffic.

What Problem This Solves

Thread Ownership treats a forwarder 409 as the ownership-conflict signal: another agent owns the Slack thread, so the outgoing thread reply must be cancelled. The first patch bounded the conflict JSON read, but an oversized or malformed 409 body could throw before the cancellation return and fall into the outer fail-open ownership-check catch. That made a conflict response capable of allowing a send.

This update keeps the bounded read but moves parse/overflow handling inside the 409 branch. The 409 status remains authoritative, so unreadable conflict bodies only degrade owner attribution to unknown; they no longer change cancellation into fail-open delivery.

User Impact

• Why it matters / User impact: In multi-agent Slack deployments, a 409 ownership conflict is the message-delivery guard that prevents one agent from replying into a thread owned by another. A bad conflict body should not bypass that guard. The repaired branch still bounds forwarder response reads and the mention cache, but preserves the user-visible cancellation semantics for all observed 409 conflicts.

Origin / follow-up

Follow-up to #101743, which targets the same Thread Ownership hardening area.

This PR keeps the patch focused on the Thread Ownership extension and updates the existing #101968 repair path after ClawSweeper identified the 409 cancellation regression. It does not close an issue; it is a focused follow-up PR intended to provide a maintainer-reviewable root-cause fix with fresh before/after behavior evidence.

Competition / linked PR analysis

The linked PR #101743 is the known related open PR for this Thread Ownership behavior area. ClawSweeper also reported overlapping hardening PR coverage, so the canonical landing path remains a maintainer decision if another PR is preferred.

This PR's narrower advantage is the now-explicit 409 conflict invariant plus proof quality: the verification drives the production Thread Ownership plugin entrypoint hooks (message_sending and message_received) against a real local HTTP forwarder, compares origin/main-style behavior to this repaired branch, and records small, oversized, and malformed 409 conflict responses plus mention-cache eviction behavior.

• Related open PR scan: fix(thread-ownership): cap mention cache and bound forwarder JSON reads #101743 is the surfaced linked candidate for this exact Thread Ownership follow-up. ClawSweeper reported additional overlapping hardening coverage; this PR should be reconciled by maintainers against that canonical landing path, but the local repair is intentionally limited to preserving 409 cancellation while keeping the bounded read and cache cap.

Scope / source-of-truth boundary

• Scope boundary: The patch only changes extensions/thread-ownership: the local extension API barrel, the Thread Ownership plugin entrypoint, and focused regression tests. It does not change Slack routing, channel ingestion, the ownership forwarder API path, request body, SSRF policy, timeout, config schema, or any other extension.
• Source-of-truth boundary: The source of truth for ownership conflicts remains the forwarder HTTP status 409. The conflict body is only optional attribution for logging. The source of truth for bypassing ownership checks remains the plugin's {channel}:{thread} mention map populated by message_received.
• Architecture boundary: The changed code sits after OpenClaw has normalized Slack hook context into message_sending / message_received events and before the Thread Ownership plugin posts to the configured forwarder. The proof covers that plugin hook boundary plus the HTTP forwarder boundary.
• Architecture / source-of-truth check: The canonical source-of-truth contract remains unchanged: forwarder 409 means another owner and must cancel the send; mention map state means the agent was directly mentioned in that Slack thread and can skip the ownership check. The patch only changes the parser/read boundary for optional owner attribution and the retention invariant for mention-map state.
• Out-of-scope boundary: This does not redefine Thread Ownership ownership semantics, add a new forwarder contract, change Slack ingestion, change plugin configuration, or introduce a new compatibility path.

Real behavior proof

• Behavior or issue addressed: Thread Ownership no longer lets unreadable forwarder 409 conflict bodies convert an ownership conflict into fail-open send delivery. It also keeps the hard 64 KiB conflict-body read limit and the 2000-entry Slack @mention bypass cache cap.

• Canonical reachability path: User/config/input → schema/type/ingestion/normalization → runtime object → request/effect: a Slack channel event reaches OpenClaw's plugin runtime as a normalized message_received or message_sending hook call; Thread Ownership resolves ctx.channelId, ctx.conversationId, event.replyToId, event.threadId, and event.metadata; message_received records the canonical {channel}:{thread} key for direct agent @mentions; message_sending checks that runtime map and otherwise posts {"agent_id": agent.id} to /api/v1/ownership/{channelId}/{threadTs}; any forwarder 409 cancels the outgoing Slack thread send even if optional owner JSON is oversized or malformed.

• Boundary crossed: The proof registered the production Thread Ownership plugin entrypoint and drove the real message_sending and message_received hook handlers. The ownership check crossed a real loopback HTTP socket to a local forwarder process returning 200 and 409 responses. The changed code does not call Slack's SaaS API directly; its channel boundary is the OpenClaw Slack hook payload, and its service boundary is the Thread Ownership forwarder HTTP request.

• Shared helper / provider constraint check: The patch uses readProviderJsonResponse from openclaw/plugin-sdk/provider-http, the shared bounded JSON response helper backed by readResponseWithLimit. The mention cache cap uses pruneMapToMaxSize from openclaw/plugin-sdk/collection-runtime, matching the shared Map-pruning helper used by other request/memory guard caches.

• Real environment tested: Local OpenClaw worktree at /media/vdb/code/ai/aispace/openclaw-worktrees/pr-101968, PR repair head 97d609c880df0196158f86a0507ed5ac82d6e4b9. The proof used Node with tsx, the production Thread Ownership plugin entrypoint, normalized Slack hook payloads, and a local HTTP forwarder bound to 127.0.0.1.

• Exact steps or command run after this patch:

  node --import tsx "$EVIDENCE_DIR/thread-ownership-live-proof.mjs" \
    "$EVIDENCE_DIR/before-thread-ownership/index.ts" before \
    "$EVIDENCE_DIR/thread-ownership-before.json"
  
  node --import tsx "$EVIDENCE_DIR/thread-ownership-live-proof.mjs" \
    "$TASK_WORKTREE/extensions/thread-ownership/index.ts" after \
    "$EVIDENCE_DIR/thread-ownership-after.json"
  
  git diff --check
  node scripts/run-vitest.mjs extensions/thread-ownership/index.test.ts

• Evidence after fix:

  thread-ownership live proof before passed; evidence=/media/vdb/code/ai/aispace/openclaw-pr-101968-evidence/thread-ownership-before.json
  thread-ownership live proof after passed; evidence=/media/vdb/code/ai/aispace/openclaw-pr-101968-evidence/thread-ownership-after.json
  git diff --check: passed
  node scripts/run-vitest.mjs extensions/thread-ownership/index.test.ts: 24 tests passed
  

  After-patch evidence excerpt:

  {
    "smallConflict": { "cancel": true },
    "oversizedConflict": { "cancel": true },
    "malformedConflict": { "cancel": true },
    "newestMentionSkippedForwarder": true,
    "oldestMentionTriggeredForwarder": true,
    "logs": {
      "info": [
        "thread-ownership: cancelled send to C123:1000.0001 — owned by agent-b",
        "thread-ownership: cancelled send to C123:1000.0002 — owned by unknown",
        "thread-ownership: cancelled send to C123:1000.0003 — owned by unknown"
      ],
      "warn": [
        "thread-ownership: conflict body unreadable (Error: thread-ownership forwarder conflict: JSON response exceeds 65536 bytes), cancelling send",
        "thread-ownership: conflict body unreadable (Error: thread-ownership forwarder conflict: malformed JSON response), cancelling send"
      ]
    }
  }

• Observed result after fix: A small 409 conflict body cancels the outgoing Slack thread send and logs the owner. An oversized 409 conflict body trips the 64 KiB bounded read, logs JSON response exceeds 65536 bytes, records owner as unknown, and still returns { cancel: true }. A malformed 409 conflict body logs malformed JSON response, records owner as unknown, and still returns { cancel: true }. After 2001 Slack @mention threads, the oldest remembered thread hits the forwarder again while the newest remembered thread still skips the forwarder, proving oldest-entry eviction without breaking the bypass for recent mentions.

• What was not tested: Production deployment load profile, real workspace traffic volume, and non-Thread-Ownership integrations. The changed code path itself is below Slack event ingestion and does not call Slack's external API; the proof exercises the OpenClaw hook payload boundary and the forwarder HTTP boundary that this patch changes.

• Fix classification: Root cause fix.

Review findings addressed

• RF-001: Fixed. Oversized and malformed 409 conflict bodies are caught inside the 409 branch and still return { cancel: true }, so unreadable conflict bodies no longer fall through to the outer fail-open catch.
• RF-002: Accepted and documented tradeoff. The 2000-entry mention cap intentionally evicts the oldest high-cardinality mention keys, sending older threads back through the forwarder. The after-proof shows oldestMentionTriggeredForwarder: true and newestMentionSkippedForwarder: true, so recent direct mentions keep the bypass while memory stays bounded.
• RF-003: Disclosed for maintainer reconciliation. fix(thread-ownership): cap mention cache and bound forwarder JSON reads #101743 and ClawSweeper-reported overlapping hardening PR coverage may overlap this behavior; this PR is intentionally narrow and now fixes the 409 cancellation semantics before maintainers choose the canonical landing path.
• RF-004: Fixed with a narrow repair. The patch preserves 409 cancellation semantics while keeping the bounded conflict-body read and the mention cache cap.
• RF-005: Fixed at extensions/thread-ownership/index.ts:201-205. Owner parsing failures now degrade to owner = "unknown"; they do not change the cancellation decision.
• RF-006: Verified. git diff --check passed with no whitespace errors.
• RF-007: Verified. node scripts/run-vitest.mjs extensions/thread-ownership/index.test.ts passed with 24 tests.

Regression Test Plan

• Target test file: extensions/thread-ownership/index.test.ts
• Scenario locked in: message_sending cancels when the forwarder returns 409 with a normal owner body, an oversized owner body, or malformed JSON. message_received retains only the newest 2000 mentioned-thread keys, so the oldest high-cardinality mention returns to the forwarder while the newest mention still skips the forwarder.
• Why this is the smallest reliable guardrail: The guardrail is intentionally narrow: it hits the two changed invariants in the Thread Ownership test file and relies on live proof for the plugin-entrypoint plus HTTP-forwarder behavior, so future changes cannot reintroduce fail-open 409 conflicts, unbounded conflict-body reads, or unbounded mention-cache retention without a focused failure.

Commands run:

git diff --check
node scripts/run-vitest.mjs extensions/thread-ownership/index.test.ts

Observed result:

Test Files  1 passed (1)
Tests  24 passed (24)
[test] passed 1 Vitest shard in 13.88s

Merge risk

• Risk labels considered: merge-risk: 🚨 message-delivery, merge-risk: 🚨 availability, merge-risk: 🚨 compatibility.
• Risk explanation: This touches message-delivery gating because a valid ownership conflict cancels a Slack thread send. It also touches availability because oversized response bodies and high-cardinality mention traffic can affect the plugin process. Compatibility risk is low because no config shape, forwarder endpoint, request payload, timeout, or normal successful response semantics changed.
• Why acceptable: Valid and unreadable 409 conflicts now consistently cancel sends, successful forwarder responses still allow sends, and non-409 forwarder/network/unexpected failures still use the existing fail-open policy. The cache cap only sends older high-cardinality mention entries back through the existing forwarder check while retaining the newest entries.

Risk / Compatibility

• Message-delivery behavior for valid small 409 conflicts is preserved: the send is still cancelled.
• Malformed or oversized 409 conflicts now match the conflict status semantics instead of the generic fail-open error path.
• Non-409 forwarder/network/unexpected errors keep the existing fail-open behavior.
• The mention cache still expires entries after five minutes and now also keeps only the newest 2000 entries.
• The cap value matches the existing Slack thread starter cache size pattern, limiting memory growth without changing normal low-cardinality behavior.

Patch quality notes

• Patch quality notes: Diff is limited to three Thread Ownership files: production entrypoint, extension API barrel, and focused regression tests. Production imports stay inside the extension's local ./api.ts barrel, which re-exports plugin SDK helpers instead of deep-importing core internals from the extension. No unrelated cleanup, broad refactor, dependency changes, lockfile changes, or docs-only changes are included.

Maintainer-ready confidence

• Maintainer-ready confidence: High. The root cause is at two local boundaries, the diff is small, related PR overlap is disclosed, and proof covers before/after behavior for all changed paths: bounded forwarder 409 reads, unreadable conflict-body cancellation, and max-size mention cache eviction.

What was not changed

• What did NOT change: No Slack channel routing or conversation ID canonicalization changes; no ownership forwarder API path, request body, timeout, or SSRF policy changes; no Thread Ownership plugin configuration shape changes; no changes outside extensions/thread-ownership; no unrelated cleanup or refactor.

Root Cause

• Root cause: The root source is a parser/error-propagation invariant violation in the 409 conflict branch: optional owner JSON parsing was allowed to throw into the same outer catch used for generic ownership-check failures, so a conflict status could be transformed into fail-open send delivery. Separately, the mention bypass cache relied only on time-based expiry, so high-cardinality message_received traffic could keep adding unique {channel}:{thread} keys until TTL cleanup.

• Why this is root-cause fix: The fix changes the response-consumption boundary where the incorrect propagation happened: 409 is handled first as the authoritative conflict signal, and owner body parsing is contained inside that branch. Parser overflow or malformed JSON now affects only owner attribution, not the cancellation decision. The cache change fixes the retention invariant at the only write point by pruning immediately after each mention key is inserted, so the map cannot exceed the configured maximum regardless of inbound mention cardinality.