Repository navigation
Discord: a mention of the app's own managed role is silently ignored #1615
Description
Problem
In Discord, typing @<app name> offers two entries with the same name: the app's bot user and the managed role Discord creates for that app. Picking the role looks the same in the sent message, but the bound PersonaBot is never woken and nobody is told why.
This is the root cause of #1609. The Host does not lose the message; it never counted as a mention of the app.
What happens today
- The Provider (
@xmanrui/dsh-im4.32.0, pin1eee207c) setsmentionedAccountfrom the nativementionsarray only, which lists users. A role mention is inmention_roles, somentionedAccountisfalse. - When the app has the Message Content intent, the Provider still forwards the message as ordinary channel text. Its received counter goes up and the Host returns accepted.
- The Host treats a group event with
mentionedAccount: falseas context only (packages/core/src/messaging/inbound.ts, default traffic). With no Conversation ingest for that channel it writes nothing: no implicit conversation entry, no Source Event, no Inbox admission, no log line. - A mention of the bot user in the same channel is admitted and answered normally.
ADR-0128 says the mention path "does not infer direct addressing from role mentions, display names or @everyone". That rule is right for ordinary roles, which can have many members. It does not discuss the app's own managed role, which belongs to exactly one app.
Evidence
Reproduced on an isolated Host built from main at be7fb070 with DSH 0.2.0-rc.2, using temporary trace logging in the default-traffic path:
| Mention chosen | mentionedAccount |
User mentions in event | Result |
|---|---|---|---|
| Managed role of the app | false |
0 | Accepted, nothing written, no reply |
| Bot user of the app | true |
1 | Implicit entry created, admitted, replied |
The same behaviour was seen on the long-run validation Host at tags long-run-v1 and long-run-v2.
Proposed behaviour
- A mention of the app's own managed role counts as a mention of the app. Discord marks that role with
tags.bot_idequal to the app's bot user id, so the check is exact. - Mentions of any other role and
@everyone/@herekeep today's behaviour. - If the role mention is not accepted as addressing, the message should at least not look received: either no received count, or a visible reason in the app's reception state.
Where the change goes
mentionedAccountis decided in the Provider (normalizeDiscordHumanTextand#acceptExternalMessagein the Discord runtime). The Host only sees the result and has no role data, so the main change is in dsh-im.- This repository then needs a new qualified Provider pin (
scripts/dev-im-provider.mjs), an update to ADR-0128, and a Discord verification record for the role-mention case. - A Discord connection guide does not exist yet; whichever behaviour is chosen, it should say which
@entry to pick.
Acceptance
- Mentioning the app's managed role in a guild channel wakes the bound Bot and it replies in place.
- Mentioning an unrelated role that the app's member holds does not wake the Bot.
-
@everyoneand@heredo not wake the Bot. - ADR-0128 records the decision.
Activity
DoodleBears commentedon Oct 15, 2026
Agent work claim
codex/local/01a13902-0d72-7872-ac0f-440e152155d5(not a DSH Session).codex/1615-discord-managed-role(Core and maintained Provider).docs: keep candidate Discord guide outside migrated site routes
docs: record packaged Discord managed-role qualification
DoodleBears commentedon Oct 15, 2026
Agent work progress — native installed-product acceptance passed
Task:
codex/local/01a13902-0d72-7872-ac0f-440e152155d5(not a DSH Session). Date: 2026-10-16 JST. State: active; review presentation and feedback still pending.The Human confirmed registered Discord QA1 was idle and requested testing through the built-in browser. The actual six-tarball
1.3.0-test.1615.1candidate, Provider.22at1fc80010ab7cfd10ecc4f63c1d46c098e829c6a6, ran in an isolated Host with official DeepSeek Flash.USER_OKand one source-referencing accepted Outbox.ROLE_OKand one source-referencing accepted Outbox; zero user mentions in the native message and canonical Source.@everyoneand@here: same negative result. Provider reception and native readback confirmed all three messages were actually received.Full verification record, Core draft #1927, maintained Provider draft #30.
Provider affected tests 96/96, shared/other-platform tests 286/286, integrated Core/packaging tests 80/80 and integration CI passed. The latest documentation-only commit has a separate CI run. Private native facts/screenshots/recording remain machine-local; a matched base/candidate visual pair and GitHub-rendered review images are still owed. A local HTML explainer is bound to Core head
20f533999d05ca2efd17d0fe707a9de27b386ac4and Provider head1fc80010ab7cfd10ecc4f63c1d46c098e829c6a6; it is not reviewer-hosted or runtime evidence. Neither PR has been merged, globally published or deployed.fix(discord): qualify own managed-role mentions in the product Provid…
DoodleBears commentedon Nov 3, 2026
Fixed by #1927 with BotHarness/dsh-im#30 and verified on Discord QA1 (2026-11-02). Ships with Provider 4.32.0-botharness.26.