feat(slack): persistent thread participation + bounded fallback by soichiyo · Pull Request #58731 · openclaw/openclaw

soichiyo · 2026-04-01T04:11:38Z

Summary

Persistent thread participation store: Thread continuation in requireMention channels was lost on gateway restart because participation state was in-memory only (24h TTL cache). Now writes to a JSON file alongside the session store, surviving restarts.
Diagnostic logging: Structured info-level logs at mention gating, thread continuation decisions, and participation recording. Thread_ts resolution failures are now always visible instead of verbose-only.
Bounded thread_ts fallback: When conversations.history fails to resolve thread_ts for messages with parent_user_id, tries conversations.replies as a second attempt before marking the message as ambiguous (instead of silently treating it as a root message).
Gating separation: Split implicitMention into implicitMention (parent is bot) and threadContinuation (bot has previously replied), making root-message gating and thread-continuation gating independently visible and controllable. Backward compatible for other channels.

Test plan

New thread-participation-store.test.ts: 9 tests (persist, read, TTL, key isolation, restart survival)
Existing prepare.test.ts: 23 tests pass (no regressions)
Existing mention-gating.test.ts: 5 tests pass
Existing message-handler.test.ts, sent-thread-cache.test.ts, missing-thread-ts.test.ts: all pass
Type check: no new errors in Slack extension
Manual: verify requireMention=true channel thread continuation survives docker compose restart
Manual: verify diagnostic logs appear in gateway.log for thread replies

greptile-apps · 2026-04-01T04:17:37Z

Greptile Summary

This PR adds persistent thread-participation state for Slack's requireMention channels so that thread-continuation decisions survive gateway restarts, alongside a bounded conversations.replies fallback for thread_ts resolution and improved diagnostic logging throughout the mention-gating pipeline.

Key changes:

thread-participation-store.ts: New flat-JSON store keyed by accountId:channelId:threadTs, written atomically via a .tmp rename, with 7-day TTL and a 10 000-entry cap. Sits behind the existing in-memory sent-thread-cache as a durability layer.
prepare.ts: implicitMention is split into implicitMention (parent is bot) and threadContinuation (bot has previously replied), each checked independently and each backed by either the hot in-memory cache or the new persistent store.
thread-resolution.ts: When conversations.history returns no thread_ts, a second attempt via conversations.replies is made before marking the message as _ambiguousThreadReply. Verbose-only logging for history failures is promoted to always-on logVerbose.
mention-gating.ts: threadContinuation is threaded through MentionGateParams and MentionGateWithBypassParams, contributing to effectiveWasMentioned independently of implicitMention. Backward-compatible for non-Slack surfaces.

Issues found:

The conversations.replies fallback passes the reply message's own ts as the ts parameter, but the Slack API expects the parent thread's ts there. This will almost always return thread_not_found, making the fallback a silent no-op while consuming a Tier-3 API call per unresolvable message.
The _ambiguousThreadReply flag is not re-applied on cached-null cache hits (Slack retries of the same message), causing the skip-reason log to fall back to the generic "no-mention" label — minor observability gap, no gating impact.
The module-level single-slot cache (cachedStore / cachedStorePath) is silently bypassed in multi-agent deployments where agents have different store paths, leading to redundant fs.readFileSync calls on every interleaved read.
The "survives simulated process restart" unit test only validates file write contents and doesn't exercise loadStore's disk-read path after clearing the in-memory cache.

Confidence Score: 5/5

Safe to merge; all issues found are P2 (observability, performance, and test-quality concerns) with no correctness or data-integrity impact on the primary happy path.

The persistent store, TTL pruning, atomic write, and mention-gating split are all correctly implemented. The in-memory sent-thread-cache remains the hot path and continues to work correctly after the refactor. No P0 or P1 findings — the conversations.replies API misuse is always caught and handled, the _ambiguousThreadReply cache gap only affects log verbosity on retries, and the single-slot module cache is a performance concern rather than a correctness issue.

extensions/slack/src/monitor/thread-resolution.ts — the resolveThreadTsFromReplies fallback should be validated against the Slack API to confirm it can actually resolve a child-reply ts to its parent thread ts before shipping to production.

Comments Outside Diff (1)

extensions/slack/src/monitor/thread-resolution.ts, line 121-124 (link)

_ambiguousThreadReply not propagated for cached-null hits

When resolution fails and null is stored in the cache, the early-return path on a subsequent lookup (e.g. a Slack retry delivery) returns the original message object without _ambiguousThreadReply:

if (cached !== undefined) {
  return cached ? { ...message, thread_ts: cached } : message;  // ← no _ambiguousThreadReply
}

The downstream effect is limited — the skip-reason log in prepare.ts will say "no-mention" instead of the more descriptive "no-mention (ambiguous thread reply…)" — so this doesn't affect correctness of the gating decision. But it is an inconsistency worth noting for observability: operators watching logs for ambiguous-thread diagnostics won't see them on Slack retries.

Prompt To Fix With AI

This is a comment left during a code review.
Path: extensions/slack/src/monitor/thread-resolution.ts
Line: 121-124

Comment:
**`_ambiguousThreadReply` not propagated for cached-null hits**

When resolution fails and `null` is stored in the cache, the early-return path on a subsequent lookup (e.g. a Slack retry delivery) returns the original `message` object without `_ambiguousThreadReply`:

```typescript
if (cached !== undefined) {
  return cached ? { ...message, thread_ts: cached } : message;  // ← no _ambiguousThreadReply
}
```

The downstream effect is limited — the skip-reason log in `prepare.ts` will say `"no-mention"` instead of the more descriptive `"no-mention (ambiguous thread reply…)"` — so this doesn't affect correctness of the gating decision. But it is an inconsistency worth noting for observability: operators watching logs for ambiguous-thread diagnostics won't see them on Slack retries.

How can I resolve this? If you propose a fix, please make it concise.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: extensions/slack/src/monitor/thread-resolution.ts
Line: 57-69

Comment:
**`conversations.replies` receives the reply's own `ts`, not the parent's**

The `ts` parameter for `conversations.replies` must be the parent/root message timestamp. When this fallback is reached, we know the message is a reply (it has `parent_user_id`) but we don't know its parent's `ts` — which is exactly what we're trying to recover. Passing the reply's own `ts` will cause Slack to return `thread_not_found` in most cases, making the fallback silently inert.

Since the result is always caught and returns `undefined`, this doesn't cause crashes, but it does fire an unnecessary Tier-3 API call (`conversations.replies` is rate-limited at Tier 3) for every message that `conversations.history` couldn't resolve. In channels where history access is restricted, this could burn rate-limit quota without any benefit.

The only scenario where this could succeed is if Slack's API internally resolves a reply ts to its parent thread — which is not documented behavior. Consider either:
- Documenting this explicitly if it is confirmed to work in testing, or
- Removing the call if tests show it never resolves anything that history didn't

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: extensions/slack/src/monitor/thread-resolution.ts
Line: 121-124

Comment:
**`_ambiguousThreadReply` not propagated for cached-null hits**

When resolution fails and `null` is stored in the cache, the early-return path on a subsequent lookup (e.g. a Slack retry delivery) returns the original `message` object without `_ambiguousThreadReply`:

```typescript
if (cached !== undefined) {
  return cached ? { ...message, thread_ts: cached } : message;  // ← no _ambiguousThreadReply
}
```

The downstream effect is limited — the skip-reason log in `prepare.ts` will say `"no-mention"` instead of the more descriptive `"no-mention (ambiguous thread reply…)"` — so this doesn't affect correctness of the gating decision. But it is an inconsistency worth noting for observability: operators watching logs for ambiguous-thread diagnostics won't see them on Slack retries.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: extensions/slack/src/thread-participation-store.test.ts
Line: 75-86

Comment:
**Restart-survival test doesn't actually exercise the cache-miss path**

The test comment acknowledges the limitation: the module-level `cachedStore` / `cachedStorePath` is not cleared between calls in the same process, so `hasPersistedThreadParticipation` in this test reads from the in-memory cache, not from disk. The test only verifies that the file was written correctly, not that `hasPersistedThreadParticipation` re-reads from disk after a restart (cache miss).

A true restart simulation would need to reset the module's internal state — either via `vi.resetModules()` + dynamic re-import, or by exposing a `_resetCacheForTesting()` helper. Without that, the test named "survives simulated process restart" is misleading: it validates `saveStore` but not `loadStore`'s disk-read path after a cold start.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: extensions/slack/src/thread-participation-store.ts
Line: 29-30

Comment:
**Module-level single-path cache is silently inefficient with multiple store paths**

`cachedStore` and `cachedStorePath` hold exactly one store at a time. If multiple agents (each with a different `storePath`) process messages concurrently and interleave their `persistThreadParticipation` / `hasPersistedThreadParticipation` calls, the cache will alternate between paths and every call will result in a synchronous `fs.readFileSync`. The Tier-1 in-memory `sent-thread-cache` remains the hot path so correctness is unaffected, but the "avoid repeated reads within the same event loop tick" comment no longer holds in multi-agent deployments.

A `Map<string, ParticipationStore>` keyed by `filePath` would make the cache work correctly for any number of agents without behavioural changes.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "feat(slack): bounded thread_ts fallback ..." | Re-trigger Greptile}

greptile-apps · 2026-04-01T04:17:41Z

+    const response = (await params.client.conversations.replies({
+      channel: params.channelId,
+      ts: params.messageTs,
+      limit: 1,
+      inclusive: true,
+    })) as { messages?: Array<{ ts?: string; thread_ts?: string }> };
+    const msg = response.messages?.[0];
+    const threadTs = normalizeThreadTs(msg?.thread_ts);
+    // Only return if the resolved thread_ts differs from the message ts
+    // (i.e., this message belongs to a parent thread).
+    if (threadTs && threadTs !== params.messageTs) {
+      return threadTs;
    }


conversations.replies receives the reply's own ts, not the parent's

The ts parameter for conversations.replies must be the parent/root message timestamp. When this fallback is reached, we know the message is a reply (it has parent_user_id) but we don't know its parent's ts — which is exactly what we're trying to recover. Passing the reply's own ts will cause Slack to return thread_not_found in most cases, making the fallback silently inert.

Since the result is always caught and returns undefined, this doesn't cause crashes, but it does fire an unnecessary Tier-3 API call (conversations.replies is rate-limited at Tier 3) for every message that conversations.history couldn't resolve. In channels where history access is restricted, this could burn rate-limit quota without any benefit.

The only scenario where this could succeed is if Slack's API internally resolves a reply ts to its parent thread — which is not documented behavior. Consider either:

Documenting this explicitly if it is confirmed to work in testing, or

Removing the call if tests show it never resolves anything that history didn't

Prompt To Fix With AI

This is a comment left during a code review. Path: extensions/slack/src/monitor/thread-resolution.ts Line: 57-69 Comment: **`conversations.replies` receives the reply's own `ts`, not the parent's** The `ts` parameter for `conversations.replies` must be the parent/root message timestamp. When this fallback is reached, we know the message is a reply (it has `parent_user_id`) but we don't know its parent's `ts` — which is exactly what we're trying to recover. Passing the reply's own `ts` will cause Slack to return `thread_not_found` in most cases, making the fallback silently inert. Since the result is always caught and returns `undefined`, this doesn't cause crashes, but it does fire an unnecessary Tier-3 API call (`conversations.replies` is rate-limited at Tier 3) for every message that `conversations.history` couldn't resolve. In channels where history access is restricted, this could burn rate-limit quota without any benefit. The only scenario where this could succeed is if Slack's API internally resolves a reply ts to its parent thread — which is not documented behavior. Consider either: - Documenting this explicitly if it is confirmed to work in testing, or - Removing the call if tests show it never resolves anything that history didn't How can I resolve this? If you propose a fix, please make it concise.

greptile-apps · 2026-04-01T04:17:45Z

+  it("survives simulated process restart (re-reads from disk)", () => {
+    persistThreadParticipation(sessionStorePath, "A1", "C123", "1700000000.000001", "main");
+
+    // Clear the module-level cache by importing fresh — we simulate restart
+    // by directly reading from disk in a new call after clearing internal cache.
+    // The simplest way: just verify the file exists and has the right content.
+    const filePath = deriveParticipationStorePath(sessionStorePath);
+    const raw = JSON.parse(fs.readFileSync(filePath, "utf-8"));
+    expect(raw["A1:C123:1700000000.000001"]).toBeDefined();
+    expect(raw["A1:C123:1700000000.000001"].agentId).toBe("main");
+    expect(raw["A1:C123:1700000000.000001"].repliedAt).toBeGreaterThan(0);
+  });


Restart-survival test doesn't actually exercise the cache-miss path

The test comment acknowledges the limitation: the module-level cachedStore / cachedStorePath is not cleared between calls in the same process, so hasPersistedThreadParticipation in this test reads from the in-memory cache, not from disk. The test only verifies that the file was written correctly, not that hasPersistedThreadParticipation re-reads from disk after a restart (cache miss).

A true restart simulation would need to reset the module's internal state — either via vi.resetModules() + dynamic re-import, or by exposing a _resetCacheForTesting() helper. Without that, the test named "survives simulated process restart" is misleading: it validates saveStore but not loadStore's disk-read path after a cold start.

Prompt To Fix With AI

This is a comment left during a code review. Path: extensions/slack/src/thread-participation-store.test.ts Line: 75-86 Comment: **Restart-survival test doesn't actually exercise the cache-miss path** The test comment acknowledges the limitation: the module-level `cachedStore` / `cachedStorePath` is not cleared between calls in the same process, so `hasPersistedThreadParticipation` in this test reads from the in-memory cache, not from disk. The test only verifies that the file was written correctly, not that `hasPersistedThreadParticipation` re-reads from disk after a restart (cache miss). A true restart simulation would need to reset the module's internal state — either via `vi.resetModules()` + dynamic re-import, or by exposing a `_resetCacheForTesting()` helper. Without that, the test named "survives simulated process restart" is misleading: it validates `saveStore` but not `loadStore`'s disk-read path after a cold start. How can I resolve this? If you propose a fix, please make it concise.

greptile-apps · 2026-04-01T04:17:46Z

+let cachedStore: ParticipationStore | null = null;
+let cachedStorePath: string | null = null;


Module-level single-path cache is silently inefficient with multiple store paths

cachedStore and cachedStorePath hold exactly one store at a time. If multiple agents (each with a different storePath) process messages concurrently and interleave their persistThreadParticipation / hasPersistedThreadParticipation calls, the cache will alternate between paths and every call will result in a synchronous fs.readFileSync. The Tier-1 in-memory sent-thread-cache remains the hot path so correctness is unaffected, but the "avoid repeated reads within the same event loop tick" comment no longer holds in multi-agent deployments.

A Map<string, ParticipationStore> keyed by filePath would make the cache work correctly for any number of agents without behavioural changes.

Prompt To Fix With AI

This is a comment left during a code review. Path: extensions/slack/src/thread-participation-store.ts Line: 29-30 Comment: **Module-level single-path cache is silently inefficient with multiple store paths** `cachedStore` and `cachedStorePath` hold exactly one store at a time. If multiple agents (each with a different `storePath`) process messages concurrently and interleave their `persistThreadParticipation` / `hasPersistedThreadParticipation` calls, the cache will alternate between paths and every call will result in a synchronous `fs.readFileSync`. The Tier-1 in-memory `sent-thread-cache` remains the hot path so correctness is unaffected, but the "avoid repeated reads within the same event loop tick" comment no longer holds in multi-agent deployments. A `Map<string, ParticipationStore>` keyed by `filePath` would make the cache work correctly for any number of agents without behavioural changes. How can I resolve this? If you propose a fix, please make it concise.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6e6985a44a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2026-04-01T04:17:47Z

+      if (!resolved) {
+        logVerbose(
+          `slack inbound: conversations.history miss for channel=${message.channel} ts=${message.ts}, trying conversations.replies fallback`,
+        );
+        resolved = await resolveThreadTsFromReplies({


Deduplicate replies fallback before caching thread_ts result

When two handlers resolve the same Slack event concurrently (for example message and app_mention with the same channel:ts), both callers await the shared conversations.history promise, then each independently runs conversations.replies and finally calls setCached. This means a later failing fallback can overwrite an earlier successful resolution with null, causing that message key to be treated as unresolved for the cache TTL and also doubling fallback API calls under contention. Keep the fallback+cache write inside the same inflight promise so only one final result wins.

Useful? React with 👍 / 👎.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8259995e47

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2026-04-14T02:57:41Z

      }

-      if (shouldLogVerbose()) {
+      setCached(cacheKey, resolved ?? null, Date.now());


Preserve ambiguous reply state in cache

setCached(cacheKey, resolved ?? null, ...) records unresolved lookups as null, but unresolved lookups now return a decorated event with _ambiguousThreadReply: true. When the same Slack event is processed again within TTL (for example concurrent message and app_mention handlers), the cache-hit path treats null as a plain miss and returns the original message, so the second caller loses the ambiguity marker and can fall back to root-message behavior. Store an explicit ambiguous-miss sentinel (or cached decorated result) so all callers get consistent thread-reply semantics.

Useful? React with 👍 / 👎.

martingarramon

Thanks for the write-up and the test coverage. Core pattern (persistent store behind hot in-memory cache, diagnostic log promotion, bounded fallback) reads soundly. A few concerns, none strictly blocking but worth addressing before merge — three beyond what the bots already flagged.

Bot-flagged risk cluster. Greptile's three P2s (reply-ts-as-parent-ts fallback, single-path module cache, test not exercising disk re-read) and Codex's two P2s (concurrent-handler race overwriting cache, ambiguous sentinel not preserved in cache) collectively suggest the thread-resolution flow hasn't been pressure-tested for concurrency or multi-agent layouts. The Map<string, ParticipationStore> fix from Greptile and the shared-inflight-promise fix from Codex both seem correct and cheap.

Beyond the bots:

threadContinuation? added to MentionGateParams / MentionGateWithBypassParams is dead code. Both types are @deprecated, and the deprecated resolveMentionGating at src/channels/mention-gating.ts:194-206 only reads implicitMention, never threadContinuation. The new API (resolveInboundMentionDecision via InboundMentionFacts.implicitMentionKinds) is what prepare.ts actually uses — correctly, via implicitMentionKindWhen("bot_thread_participant", ...) at the persistent-check site. So the field additions to the deprecated types have no runtime effect. Either remove them or wire them into the deprecated gate for non-Slack callers that may still use it. The field comment claiming it "contributes to effectiveWasMentioned independently" is currently untrue.
_ambiguousThreadReply has zero consumers. The PR introduces the sentinel on SlackMessageEvent (types.ts:43) and sets it in thread-resolution.ts when both history + replies fallbacks fail, with a comment saying "downstream should not treat this as a genuine root message." But grepping the repo finds no code that reads the field. As shipped, an ambiguous reply is functionally indistinguishable from a root message in the downstream path. Is a follow-up PR intended to wire this, or was a consumer missed? If the former, worth saying so explicitly in the body; if the latter, the PR isn't complete yet.
Write amplification on the hot path. persistThreadParticipation is called from dispatch.ts:793-808 on every reply delivery. Each call rewrites the entire store via sync fs.writeFileSync + renameSync (thread-participation-store.ts:57-64). At MAX_ENTRIES = 10_000 and ~100 bytes per entry, that's ~1MB rewritten synchronously per reply. On a tenant with high concurrent thread throughput, this blocks the event loop and raises IOPS pressure. Consider: (a) debounced writes batched every N seconds, (b) append-only log with periodic compaction, or (c) keep persistence but make saveStore async + fire-and-forget so it stays off the ack path. pruneExpired also runs on every write — worth lazy-pruning only when size exceeds the cap given the O(n log n) sort cost.

Architectural question on the replies fallback. Greptile's P2 claim that conversations.replies with the reply's own ts returns thread_not_found matches the documented Slack API contract. The guard if (threadTs && threadTs !== params.messageTs) return threadTs; at thread-resolution.ts:155 implies you've observed it occasionally working — is that documented behavior or undocumented? If undocumented, worth flagging in the code comment and in the PR body so it doesn't turn into a Tier-3-quota silent regression when Slack tightens the API. If documented or test-validated, please link the evidence — otherwise the fallback is strictly quota burn for inert lookups.

Minor, non-blocking: loadStore at thread-participation-store.ts:43-51 catches all errors (including JSON parse) and returns {}, which the next saveStore will then persist. If the file is ever briefly corrupt for any reason outside the atomic-rename path (manual edit, backup-restore mishap), the recovery pattern silently wipes historical data. A noisier failure on parse error (fail-open in-memory only, never write back {} as replacement) is safer for durability. Low probability but zero-cost to log loud and skip the overwrite.

Happy to re-review once the concurrency + dead-code cleanup lands.

openclaw-barnacle · 2026-04-30T04:42:43Z

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

clawsweeper · 2026-05-01T00:44:37Z

Thanks for the context here. I swept through the related work, and this is now duplicate or superseded.

Close as superseded. The central Slack restart-survival problem has landed on current main through the merged SDK-backed persistence path, while this branch still carries a competing JSON participation store and is no longer the right merge target.

So I’m closing this here and keeping the remaining discussion on the canonical linked item.

Review details

Best possible solution:

Keep the merged SDK-backed Slack participation persistence on main as the canonical implementation, and handle any future missing-thread_ts diagnostics as a separate Slack-owned follow-up with focused tests and API validation.

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

Yes. The original bug is reproducible on the pre-fix path by recording Slack thread participation, restarting or clearing process memory, then processing an unmentioned reply in a requireMention Slack thread; current main now has source and test proof for persistent lookup and memory backfill.

Is this the best way to solve the issue?

No. This PR was useful source work, but the best solution is the merged #75583 path because it uses the current plugin state-store API instead of adding a second custom JSON persistence layer.

Security review:

Security review cleared: The PR diff adds local Slack participation persistence, Slack API handling, and tests, but no new dependency, workflow, secret handling, package source, or command-execution surface.

What I checked:

Superseding implementation is on main: Commit d0ec3d1 is an ancestor of current HEAD ad1e14a and is titled "slack: persist thread participation best-effort (slack: persist thread participation best-effort #75583)". (d0ec3d1f09b0)
Current main uses the SDK-backed Slack participation store: Slack now opens the bundled-plugin keyed store under namespace slack.thread-participation with TTL and entry cap, then registers participation asynchronously while keeping the in-memory cache as the hot path. (extensions/slack/src/sent-thread-cache.ts:74, ad1e14af532f)
Current main checks persisted participation during mention gating: Slack prepare builds the bot_thread_participant implicit mention kind from hasSlackThreadParticipationWithPersistence, so restart-cold reads can recover the participation signal. (extensions/slack/src/monitor/message-handler/prepare.ts:357, ad1e14af532f)
Current main records route metadata on reply delivery: Slack dispatch records participation after a delivered reply and passes agentId into recordSlackThreadParticipation, matching the merged follow-up's future per-agent routing shape. (extensions/slack/src/monitor/message-handler/dispatch.ts:1173, ad1e14af532f)
Current main has focused persistence coverage: The sent-thread-cache tests cover registering into the persistent store, clearing memory, reading back from persistence, and avoiding repeat persistent lookups after the memory backfill. (extensions/slack/src/sent-thread-cache.test.ts:95, ad1e14af532f)
Release provenance check: The changelog entry is still in Unreleased, and git tag --contains d0ec3d1f09b08fc8edadf30eb50a28ae4a24f71d returned no tag, so the superseding fix is on current main after the latest release rather than in a shipped tag yet. (CHANGELOG.md:16, ad1e14af532f)

Likely related people:

amknight: Authored the merged SDK-backed Slack persistence commit and the related plugin state-store direction that current main now uses for this behavior. (role: recent maintainer and superseding implementation author; confidence: high; commits: d0ec3d1f09b0, fe457b26fac0; files: extensions/slack/src/sent-thread-cache.ts, extensions/slack/src/monitor/message-handler/prepare.ts, extensions/slack/src/monitor/message-handler/dispatch.ts)
luijoc: Merged PR feat(slack): track thread participation for auto-reply without @mention #29165 introduced the original Slack in-memory thread participation cache that this PR and the superseding main change extend across restarts. (role: introduced original behavior; confidence: medium; commits: 5079d0c4c389; files: extensions/slack/src/sent-thread-cache.ts, extensions/slack/src/monitor/message-handler/prepare.ts, extensions/slack/src/monitor/message-handler/dispatch.ts)
steipete: Current local blame for the pre-persistence cache and Slack routing baseline points at commit 29d9a30, so this is a useful routing candidate for recent main-state context. (role: recent baseline maintainer; confidence: low; commits: 29d9a30497; files: extensions/slack/src/sent-thread-cache.ts, extensions/slack/src/monitor/message-handler/prepare.ts, extensions/slack/src/monitor/message-handler/dispatch.ts)

Codex review notes: model gpt-5.5, reasoning high; reviewed against ad1e14af532f; fix evidence: commit d0ec3d1f09b0, main fix timestamp 2026-05-01T12:10:09Z.

…ase 1) Thread continuation in Slack channels with requireMention was fragile because participation state lived only in a 24-hour in-memory cache that was lost on process restart. This caused threads to silently drop after gateway updates. Phase 1 changes: - Add persistent thread participation store (JSON file alongside session store) so restart no longer loses thread continuation - Add structured diagnostic logs at mention gating, thread continuation decisions, and participation recording to make silent failures traceable - Elevate thread_ts resolution failure from verbose-only to always-visible warning since it causes silent degradation - Pass storePath through PreparedSlackMessage so dispatch can persist participation without re-resolving the path Note: pre-commit tsgo blocked by pre-existing matrix test errors (5 errors in extensions/matrix/ unrelated to this change). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

…on gating (Phase 2) Phase 2A — thread_ts resolution improvement: - Add conversations.replies as bounded fallback when conversations.history fails to resolve thread_ts for messages with parent_user_id - Mark unresolvable messages as _ambiguousThreadReply instead of silently treating them as root messages - Log ambiguous thread reply status in mention skip reasons Phase 2B — gating separation: - Split implicitMention into two distinct signals: - implicitMention: bot is the thread parent (root-message signal) - threadContinuation: bot has previously replied (participation signal) - Add threadContinuation as a first-class parameter to mention gating so root-message gating and thread-continuation gating are independently visible in logs and code - Backward compatible: threadContinuation is optional, existing callers (Teams, Google Chat, etc.) are unaffected Note: pre-commit tsgo blocked by pre-existing matrix test errors (5 errors in extensions/matrix/ unrelated to this change). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

…ixture

soichiyo · 2026-05-01T12:20:15Z

I rebased the branch onto current main and adjusted it to use the SDK-backed Slack thread participation persistence that landed there, removing the competing JSON participation store.

Since this PR was closed as superseded before the updated head propagated, I opened a clean follow-up here: #75630.

openclaw-barnacle Bot added channel: slack Channel integration: slack size: M labels Apr 1, 2026

greptile-apps Bot reviewed Apr 1, 2026

View reviewed changes

chatgpt-codex-connector Bot reviewed Apr 1, 2026

View reviewed changes

soichiyo force-pushed the feat/slack-thread-continuity-phase1 branch 2 times, most recently from 363f8af to 8259995 Compare April 14, 2026 02:51

chatgpt-codex-connector Bot reviewed Apr 14, 2026

View reviewed changes

martingarramon reviewed Apr 18, 2026

View reviewed changes

amknight mentioned this pull request Apr 24, 2026

feat(plugin-sdk): add persistent keyed store helper #70626

Closed

16 tasks

clawsweeper Bot mentioned this pull request Apr 26, 2026

fix(slack): persist thread participation cache to survive gateway restarts [claude, human developer oversight] #33845

Closed

BingqingLyu mentioned this pull request Apr 27, 2026

feat(slack): persistent thread participation + bounded fallback BingqingLyu/openclaw#1762

Open

7 tasks

amknight mentioned this pull request Apr 29, 2026

feat(plugins): add SQLite plugin state store #74190

Merged

openclaw-barnacle Bot added the stale Marked as stale due to inactivity label Apr 30, 2026

openclaw-barnacle Bot removed the stale Marked as stale due to inactivity label May 1, 2026

clawsweeper Bot mentioned this pull request May 1, 2026

slack: persist thread participation best-effort #75583

Merged

soichiyo and others added 6 commits May 1, 2026 21:03

Docker: expose openclaw CLI in runtime image

62fc6db

fix(slack): remove redundant Boolean cast and add storePath to test f…

94c1790

…ixture

fix(slack): add logger stub to dispatch preview-fallback test fixture

d4eda5f

fix(slack): address thread continuation review feedback

c825064

soichiyo force-pushed the feat/slack-thread-continuity-phase1 branch from e57b7e9 to c825064 Compare May 1, 2026 12:12

clawsweeper Bot closed this May 1, 2026

soichiyo mentioned this pull request May 1, 2026

fix(slack): harden thread continuation gating #75630

Open

		let cachedStore: ParticipationStore \| null = null;
		let cachedStorePath: string \| null = null;

Uh oh!

Conversation

soichiyo commented Apr 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Test plan

Uh oh!

greptile-apps Bot commented Apr 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Greptile Summary

Confidence Score: 5/5

Comments Outside Diff (1)

Uh oh!

greptile-apps Bot Apr 1, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps Bot Apr 1, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps Bot Apr 1, 2026

Choose a reason for hiding this comment

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot Apr 1, 2026

Choose a reason for hiding this comment

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

martingarramon left a comment

Choose a reason for hiding this comment

Uh oh!

openclaw-barnacle Bot commented Apr 30, 2026

Uh oh!

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

Uh oh!

Uh oh!

soichiyo commented May 1, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

soichiyo commented Apr 1, 2026 •

edited

Loading

greptile-apps Bot commented Apr 1, 2026 •

edited

Loading

clawsweeper Bot commented May 1, 2026 •

edited

Loading