fix(mattermost): return 'unknown' ChatType when channel type is not resolvable by dave · Pull Request #57970 · openclaw/openclaw

dave · 2026-03-30T22:31:48Z

Summary

Problem: mapMattermostChannelTypeToChatType returned "channel" for null/undefined input, making a failed channel lookup indistinguishable from a successful public-channel lookup.
Why it matters: When a channel lookup fails (e.g. missing channel type in WebSocket event), posts were routed to the wrong agent session — appearing in the main channel instead of the correct thread or DM session.
What changed: mapMattermostChannelTypeToChatType(null/undefined) now returns "unknown". All dispatch paths (handlePost, dispatchButtonClick, handleReactionEvent, resolveSessionKey) early-exit on "unknown" with a verbose log drop instead of silently misrouting. "unknown" added to ChatType, MattermostChatTypeKey, and the ok: false branch of MattermostCommandAuthDecision. Type cascade fixes in SlashInvocationAuth, resolveSlackReplyToMode, and buildChannelOutboundSessionRoute.
What did NOT change: The fallback for non-null unrecognised type strings (e.g. "x") still returns "channel" — only the null/undefined case is affected.

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Related fix(mattermost): route thread replies correctly when replyToMode is off #57565 (fix/mattermost-thread-id-on-replyto-off — depends on this PR landing first)
This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

Root cause: mapMattermostChannelTypeToChatType had no guard for the null/undefined case — it fell through to return "channel", treating a missing channel type as a successful public-channel match.
Missing detection / guardrail: No test covered the null/undefined input path; the function's return type didn't include "unknown", so a wrong fallback was structurally invisible.
Prior context: The function was introduced alongside the Mattermost channel routing logic; the null case was never explicitly handled.
Why this regressed now: It was always wrong — first surfaced clearly when testing PR fix(mattermost): route thread replies correctly when replyToMode is off #57565, where bot replies were observed landing in the main channel instead of the originating thread.
If unknown, what was ruled out: N/A

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: monitor-gating.test.ts, monitor.channel-kind.test.ts
Scenario the test should lock in: mapMattermostChannelTypeToChatType(undefined) and mapMattermostChannelTypeToChatType(null) return "unknown", not "channel".
Why this is the smallest reliable guardrail: The mapping function is pure and deterministic — a direct unit test on the null/undefined inputs is the minimal reliable check.
Existing test that already covers this: None (tests previously asserted "channel" for undefined).
If no new test is added, why not: N/A — new assertions added to both test files.

User-visible / Behavior Changes

When a Mattermost channel lookup fails (channel type missing from event), the post/reaction/button click is now silently dropped (with a verbose log) instead of being misrouted to the wrong agent session. In practice this affects only broken/degenerated WebSocket events — normal Mattermost events always include a channel type.

Diagram (if applicable)

Before:
mapMattermostChannelTypeToChatType(null) -> "channel" -> routes to wrong session

After:
mapMattermostChannelTypeToChatType(null) -> "unknown" -> handlePost early-exits, post dropped

Security Impact (required)

New permissions/capabilities? No
Secrets/tokens handling changed? No
New/changed network calls? No
Command/tool execution surface changed? No
Data access scope changed? No

Repro + Verification

Environment

OS: macOS 15.3
Runtime/container: Node 22, OpenClaw 2026.3.28
Model/provider: N/A (routing layer, no model involved)
Integration/channel: Mattermost
Relevant config (redacted): Standard Mattermost account config

Steps

Start gateway with Mattermost account configured
Send a message in a channel where the WebSocket event is missing channel_type (or simulate by patching resolveChannelInfo to return null)
Observe that with the fix, the post is dropped with a verbose log; without the fix it misroutes to the main channel session

Expected

Post silently dropped, mattermost: drop post (cannot determine channel type ...) logged at verbose level

Actual (before fix)

Post treated as a public channel message, routed to main channel session

Evidence

Failing test/log before + passing after (unit tests updated: mapMattermostChannelTypeToChatType(undefined) expectation changed from "channel" to "unknown")
Synthetic test on 2026.3.28: confirmed agent replies landed in main channel instead of originating thread when channel type could not be resolved

Human Verification (required)

Verified scenarios: tsgo type check passes clean. Unit tests pass: monitor-gating.test.ts, monitor.channel-kind.test.ts, monitor-auth.test.ts. Pre-commit checks (pnpm check) pass.
Edge cases checked: Unrecognised non-null strings (e.g. "x") still return "channel" — only null/undefined is affected.
What you did not verify: Live Mattermost integration test with a real server producing a null channel type event.

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
Config/env changes? No
Migration needed? No

Risks and Mitigations

Risk: Posts that previously misrouted to the main channel session will now be silently dropped.
- Mitigation: This only affects events where the channel type is genuinely missing — which represents broken/degenerated events that were already producing wrong behavior. Dropping is strictly better than misrouting.

greptile-apps · 2026-03-30T22:35:01Z

Greptile Summary

This PR correctly fixes the root cause of a misrouting bug: when mapMattermostChannelTypeToChatType receives a null/undefined channel type (i.e., the channel lookup failed), it now returns "unknown" instead of "channel", making a failed lookup distinguishable from a successful public-channel lookup. All downstream dispatch paths (handlePost, dispatchButtonClick, handleReactionEvent, resolveSessionKey) are updated to guard against "unknown" and early-exit or degrade gracefully, and the ChatType union, MattermostChatTypeKey, and related types are extended consistently.

Key changes:

mapMattermostChannelTypeToChatType(null | undefined) → "unknown" (was "channel")
All Mattermost dispatch paths drop or short-circuit on kind === "unknown" with verbose logging
SlashInvocationAuth refactored to a discriminated union so callers can type-narrow after an ok check
resolveSlackReplyToMode guarded against indexing replyToModeByChatType with "unknown"
buildChannelOutboundSessionRoute peer parameter widened to RoutePeer

One inconsistency found: In slash-http.ts, the authorizeSlashInvocation function still returns kind: "channel" / chatType: "channel" when the channel lookup fails (line 135–136), even though the SlashInvocationAuth ok: false branch was widened to permit "unknown". There is no runtime impact — the caller exits before consuming those fields when ok === false — but it leaves type and implementation out of sync.

Confidence Score: 5/5

Safe to merge — the fix is correct and complete across all main dispatch paths; the one inconsistency in slash-http.ts has no runtime impact.
All P0/P1 concerns are addressed. The only finding is a P2 style inconsistency in slash-http.ts where the implementation returns "channel" instead of "unknown" in an ok: false branch that is never consumed by the caller. The core fix and all guard paths are sound.
extensions/mattermost/src/mattermost/slash-http.ts lines 135–136 — implementation value ("channel") doesn't match the newly widened type ("unknown" allowed); no functional impact but worth aligning for consistency.

Comments Outside Diff (1)

extensions/mattermost/src/mattermost/slash-http.ts, line 135-136 (link)

kind/chatType not updated to "unknown" in channel-lookup-failure branch

The PR widened the ok: false branch of SlashInvocationAuth to include "unknown" for kind/chatType, but the implementation inside authorizeSlashInvocation still returns "channel" when channelInfo is null. This leaves the type and the implementation inconsistent.

In practice this doesn't affect routing because the caller at line 289 (if (!auth.ok) { sendJsonResponse(...); return; }) exits before consuming kind/chatType — but it undermines the intent of the discriminated union refactor and could mislead a future caller that reads those fields from the ok: false result.

Prompt To Fix With AI

This is a comment left during a code review.
Path: extensions/mattermost/src/mattermost/slash-http.ts
Line: 135-136

Comment:
**`kind`/`chatType` not updated to `"unknown"` in channel-lookup-failure branch**

The PR widened the `ok: false` branch of `SlashInvocationAuth` to include `"unknown"` for `kind`/`chatType`, but the implementation inside `authorizeSlashInvocation` still returns `"channel"` when `channelInfo` is null. This leaves the type and the implementation inconsistent.

In practice this doesn't affect routing because the caller at line 289 (`if (!auth.ok) { sendJsonResponse(...); return; }`) exits before consuming `kind`/`chatType` — but it undermines the intent of the discriminated union refactor and could mislead a future caller that reads those fields from the `ok: false` result.



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/mattermost/src/mattermost/slash-http.ts
Line: 135-136

Comment:
**`kind`/`chatType` not updated to `"unknown"` in channel-lookup-failure branch**

The PR widened the `ok: false` branch of `SlashInvocationAuth` to include `"unknown"` for `kind`/`chatType`, but the implementation inside `authorizeSlashInvocation` still returns `"channel"` when `channelInfo` is null. This leaves the type and the implementation inconsistent.

In practice this doesn't affect routing because the caller at line 289 (`if (!auth.ok) { sendJsonResponse(...); return; }`) exits before consuming `kind`/`chatType` — but it undermines the intent of the discriminated union refactor and could mislead a future caller that reads those fields from the `ok: false` result.

```suggestion
      kind: "unknown",
      chatType: "unknown",
```

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

_{Reviews (1): Last reviewed commit: "fix: return 'unknown' ChatType when Matt..." | Re-trigger Greptile}

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 41bb3489fb

ℹ️ About Codex in GitHub

Codex has been enabled to automatically 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 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

dave · 2026-03-31T00:31:23Z

All bot review comments addressed:

Greptile P2 (slash-http kind/chatType inconsistency): fixed in 86785cb
Codex P1 (resolveSessionKey wrong-session contamination): fixed in 8d10072 — the throw is now before resolveAgentRoute so no route is computed or session key returned for unknown kinds
Contributor suggestion (comment on early-return): added clarifying comment, then superseded by the throw refactor

CI and pnpm check pass locally. Ready for review.

cc @mukhtharcm — this is a prerequisite for #57565 (thread-id fix with replyTo off).

…solvable Previously, mapMattermostChannelTypeToChatType returned "channel" for null/undefined input, masking failed channel lookups as valid routing state. All dispatch paths (handlePost, dispatchButtonClick, handleReactionEvent, resolveSessionKey) now early-exit on "unknown" instead of silently routing to the wrong session. monitor-auth's unknown-channel deny path now correctly sets kind/chatType to "unknown". SlashInvocationAuth updated to discriminated union; resolveSlackReplyToMode guards against "unknown" indexing. Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

…anch Addresses Greptile review comment: the local channel-lookup-failure path in authorizeSlashInvocation was still returning kind: "channel", inconsistent with the discriminated union refactor and monitor-auth's unknown-channel deny. Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

Addresses contributor review suggestion: add a comment explaining why we return the base session key early when kind is 'unknown', and why this is safe (handlePost drops the post before the session key is used for routing). Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

…eturning coerced key Addresses Codex P1 review: returning a coerced 'channel' session key caused the system event to be enqueued into the wrong session before dispatchButtonClick's guard ever ran. Throwing instead causes the caller's try/catch in interactions.ts to skip enqueueSystemEvent entirely, truly failing closed. Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

…onKey The throw for unknown kind was placed after resolveAgentRoute, doing unnecessary work. Move it earlier to also eliminate the kind coercion in the peer object. Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 49c8e1805b

ℹ️ About Codex in GitHub

Codex has been enabled to automatically 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 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

chatgpt-codex-connector · 2026-03-31T22:06:50Z

+    if (kind === "unknown") {
+      logVerboseMessage(
+        `mattermost: drop post (cannot determine channel type for ${channelId}, post=${post.id ?? "?"})`,
+      );
+      return;


Avoid deduping posts before unknown-channel drop

This new kind === "unknown" early return drops the post after recentInboundMessages.check(...) has already marked its message ID as seen, so transient channel-type resolution failures can now cause avoidable message loss. If Mattermost resends/replays the same post ID after channel lookup recovers, the retry is treated as a duplicate and skipped for the full dedupe TTL instead of being processed.

Useful? React with 👍 / 👎.

Fixed in 0eb76ff. Moved the unknown-channel guard to run before recentInboundMessages.check(), using payload.data?.channel_type which is available immediately without any async lookup. This way a transient unknown-channel post is dropped before its ID is registered in the dedup tracker.

…tracker Addresses Codex review: the kind === "unknown" guard was placed after recentInboundMessages.check(), so a transient unknown-channel post would mark its ID as seen before being dropped. If Mattermost replayed the same post after channel recovery, it would be incorrectly deduped. Move the check before the dedup registration, using payload.data.channel_type which is available immediately without a channelInfo lookup. Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 0eb76ff8d6

ℹ️ About Codex in GitHub

Codex has been enabled to automatically 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 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

chatgpt-codex-connector · 2026-04-01T00:29:09Z

+    const channelTypeFromEvent = payload.data?.channel_type;
+    if (mapMattermostChannelTypeToChatType(channelTypeFromEvent) === "unknown") {
+      logVerboseMessage(


Defer unknown-channel drop until fallback lookup runs

handlePost now returns early when payload.data?.channel_type maps to "unknown", but channel_type is optional on MattermostEventPayload and this return happens before resolveChannelInfo(channelId) is consulted. In the channel_type-missing case, we drop the message immediately even when the channel API lookup could still provide a valid type, so inbound posts are lost unnecessarily. This guard should use the existing channelTypeFromEvent ?? channelInfo?.type fallback path before deciding to drop.

Useful? React with 👍 / 👎.

Fixed in 3779f15. The early guard now calls resolveChannelInfo when channelTypeFromEvent maps to unknown — if the API returns a valid type we continue normally, only dropping when both the event field AND the API fallback fail. The second resolveChannelInfo call in the normal path hits the cache (same tick) so no extra network request is made.

Codex review: dropping immediately when payload.data.channel_type is missing lost messages that the API lookup could have recovered. Now the early guard only drops when both the event field AND the resolveChannelInfo API fallback return unknown. The second resolveChannelInfo call hits the cache (same tick) so no extra network request is made. Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 3779f15360

ℹ️ About Codex in GitHub

Codex has been enabled to automatically 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 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

chatgpt-codex-connector · 2026-04-01T00:59:33Z


    const channelInfo = await resolveChannelInfo(channelId);
-    const channelType = payload.data?.channel_type ?? channelInfo?.type ?? undefined;
+    const channelType = channelTypeFromEvent ?? channelInfo?.type ?? undefined;


Use fallback channel type when event type is blank

handlePost now does a fallback lookup when payload.data.channel_type maps to "unknown", but the later assignment still uses channelTypeFromEvent ?? channelInfo?.type. If Mattermost sends an empty string for channel_type, that expression keeps the empty string (because it is not null/undefined), so kind becomes "unknown" and the post is dropped even when resolveChannelInfo(channelId) returned a valid type. This creates avoidable message loss on malformed-but-recoverable events.

Useful? React with 👍 / 👎.

clawsweeper · 2026-04-28T22:15:33Z

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

Close as superseded: current main still has the Mattermost missing-channel-type bug, but the same remaining work is now tracked by a newer, narrower Mattermost-only PR with maintainer routing and better proof, while this branch still has a functional fallback bug and widens the public ChatType/SDK contract.

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

Review details

Best possible solution:

Use #78530 or an equivalent Mattermost-local fail-closed implementation, then rebase the dependent Mattermost thread-routing PR onto that result.

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

Yes. Source inspection on current main shows missing Mattermost channel type still maps to channel and is consumed by routing, and the PR head regression is reproducible from the blank-string channel_type path at extensions/mattermost/src/mattermost/monitor.ts:1063.

Is this the best way to solve the issue?

No. Failing closed is the right direction, but this branch still drops recoverable blank event types and broadens shared ChatType/SDK contracts; the Mattermost-local replacement PR is the narrower maintainable path.

Security review:

Security review cleared: The diff does not add dependencies, workflows, package resolution changes, secret handling, permissions, or new command execution surfaces; the concerns are functional/API-contract ones.

What I checked:

Current main still has the original mapper fallback: On current main, mapMattermostChannelTypeToChatType(undefined) returns channel, and the adjacent trusted-kind helper defaults to channel without a fallback, so the root bug is not implemented on main. (extensions/mattermost/src/mattermost/monitor-gating.ts:3, d4c751998910)
Current tests still lock the old behavior: The current Mattermost gating test still expects mapMattermostChannelTypeToChatType(undefined) to be channel, confirming current main has not adopted this PR's intended behavior. (extensions/mattermost/src/mattermost/monitor-gating.test.ts:14, d4c751998910)
Current routing consumes the fallback: Mattermost button session-key and button-dispatch paths on current main derive routing from mapMattermostChannelTypeToChatType(channelInfo?.type) before resolving agent routes, so an unresolved type can still be treated as a normal channel path. (extensions/mattermost/src/mattermost/monitor.ts:617, d4c751998910)
This PR still drops recoverable blank event types: At the PR head, channelTypeFromEvent ?? channelInfo?.type keeps a blank string from the event instead of using the valid API fallback, so kind becomes unknown and the post is dropped even when the lookup recovered the type. (extensions/mattermost/src/mattermost/monitor.ts:1063, 3779f1536027)
Newer canonical PR covers the same root cause locally: The newer open PR https://github.com/openclaw/openclaw/pull/78530 handles missing and blank Mattermost channel types inside the Mattermost plugin, adds regression coverage, has maintainer and proof: sufficient labels, and avoids widening shared ChatType/SDK contracts. (extensions/mattermost/src/mattermost/monitor-gating.ts:4, d9e970eb28a4)
Replacement PR carries event-or-API type ordering: The replacement PR resolves the first non-empty event/API channel type, drops only when neither source resolves, and keeps the fix in Mattermost runtime code. (extensions/mattermost/src/mattermost/monitor.ts:1282, d9e970eb28a4)

Likely related people:

steipete: Recent GitHub path history shows repeated Mattermost monitor/auth/interaction refactors and plugin SDK surface work touching the affected routing/auth files. (role: recent area contributor; confidence: high; commits: 827b0de0ce74, a0fb7fb04547, 05eda57b3c72; files: extensions/mattermost/src/mattermost/monitor.ts, extensions/mattermost/src/mattermost/monitor-auth.ts, extensions/mattermost/src/mattermost/interactions.ts)
vincentkoc: Recent Mattermost-specific commits touched the monitor and gating helper area, including DM/thread routing behavior adjacent to this channel-type bug. (role: Mattermost routing contributor; confidence: high; commits: 59fb5fd3a7a4, be438cf887ce, 3546a5400317; files: extensions/mattermost/src/mattermost/monitor-gating.ts, extensions/mattermost/src/mattermost/monitor.ts, extensions/mattermost/src/mattermost/monitor-auth.ts)
mukhtharcm: History shows the Mattermost interactive model picker work introduced nearby button interaction behavior now affected by missing channel-type routing guards. (role: adjacent interaction surface contributor; confidence: medium; commits: 4f08dcccfd71; files: extensions/mattermost/src/mattermost/interactions.ts, extensions/mattermost/src/mattermost/monitor.ts, extensions/mattermost/src/mattermost/monitor-auth.ts)

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

openclaw-barnacle Bot added channel: mattermost Channel integration: mattermost channel: slack Channel integration: slack size: S labels Mar 30, 2026

This comment was marked as spam.

Sign in to view

chatgpt-codex-connector Bot reviewed Mar 30, 2026

View reviewed changes

Comment thread extensions/mattermost/src/mattermost/monitor.ts Outdated

dave force-pushed the fix/mattermost-unknown-chat-type branch from 8d10072 to 1b5302e Compare March 30, 2026 22:44

dave mentioned this pull request Mar 31, 2026

fix(mattermost): route thread replies correctly when replyToMode is off #57565

Closed

19 tasks

dave and others added 5 commits April 1, 2026 09:01

dave force-pushed the fix/mattermost-unknown-chat-type branch from 1b5302e to 49c8e18 Compare March 31, 2026 22:01

chatgpt-codex-connector Bot reviewed Mar 31, 2026

View reviewed changes

chatgpt-codex-connector Bot reviewed Apr 1, 2026

View reviewed changes

clawsweeper Bot mentioned this pull request May 6, 2026

fix(mattermost): handle missing channel types #78530

Closed

clawsweeper Bot closed this May 11, 2026

Uh oh!

Uh oh!

Conversation

dave commented Mar 30, 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

Root Cause / Regression History (if applicable)

Regression Test Plan (if applicable)

User-visible / Behavior Changes

Diagram (if applicable)

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual (before fix)

Evidence

Human Verification (required)

Review Conversations

Compatibility / Migration

Risks and Mitigations

Uh oh!

greptile-apps Bot commented Mar 30, 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!

This comment was marked as spam.

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

dave commented Mar 31, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot Mar 31, 2026

Choose a reason for hiding this comment

Uh oh!

dave 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!

dave 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!

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

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

dave commented Mar 30, 2026 •

edited

Loading

greptile-apps Bot commented Mar 30, 2026 •

edited

Loading

clawsweeper Bot commented Apr 28, 2026 •

edited

Loading