* fix(discord): scope command-deploy cache by application id
Multi-bot Discord setups share a single command-deploy-cache.json under the
state dir. Cache keys were unscoped (`global:reconcile`, `guild:<id>`), so a
later account whose command set hashed identically to an earlier account would
hit the shared hash and skip its own application's command reconcile entirely
— Discord's Integration panel showed 'This application has no commands' for
the secondary bot even though gateway connect, application id, and token were
all valid.
Scope every cache key with `app:<clientId>:` so each Discord application
reconciles independently. Add regression tests covering: two applications with
identical command sets each call REST against their own application; a single
application with the same command set still hits the persisted cache; the
on-disk cache JSON contains application-scoped keys.
Fixes#77359.
* fix(discord): merge on-disk hashes inside persistHashes to survive concurrent writes
Codex follow-up on #77359 noted that server-channels.ts can start multiple
Discord deployers concurrently, so two deployers that both load the cache
file before either persists end up with the second writer overwriting the
first writer's app-scoped key — defeating the rate-limit cache that the
file exists to provide.
Inside persistHashes, re-read the on-disk cache and merge it with our
in-memory entries before the rename. Our in-memory entries always win on
key collisions (we just produced them); on-disk entries we don't have in
memory are preserved. Refresh in-memory state after the write so future
writes from the same deployer also keep entries other deployers added.
This is the lighter of the two repairs the codex review suggested
(re-read/merge vs serialize writes); it covers the realistic case where
one deployer writes before the other persists. Add a regression test that
exercises the load-then-other-deployer-writes-then-persist sequence.
* fix(discord): serialize command-deploy cache persists via in-process mutex
Codex follow-up on #77367 noted: re-read-before-write inside persistHashes
isn't enough — two deployers running persistHashes in true parallel can
both read the same snapshot before either writes, and the later rename
overwrites the earlier writer's app-scoped entries.
Add a module-level Map<storePath, Promise<void>> mutex and wrap the
read-merge-write cycle in withCachePersistLock so concurrent persists for
the same on-disk path serialize. In-process is sufficient because Discord
deployers only run inside the gateway process.
New regression test fires three deployers via Promise.all on the same
tick and asserts all three application-scoped entries survive — pre-fix
this race lost at least one entry.
* fix(discord): add override modifier on StaticCommand.description to satisfy strict TS
Current main enables noImplicitOverride; the StaticCommand test helper
re-declares the concrete BaseCommand.description property, which now
requires an explicit 'override' modifier (TS4114).
* test(discord): suppress typescript/unbound-method on vitest mock refs
The createRest() helper returns vi.fn() handlers cast as RequestClient,
so expect(rest.get).toHaveBeenCalledTimes(...) triggers
typescript/unbound-method 12 times. File-level disable: these are
vitest mock identities, not unbound class methods.
* fix(discord): clean up command cache lock
Signed-off-by: sallyom <somalley@redhat.com>
---------
Signed-off-by: sallyom <somalley@redhat.com>
Co-authored-by: sallyom <somalley@redhat.com>
* fix(discord): normalize whitespace in command description comparison
Discord server-side storage collapses consecutive whitespace and removes
whitespace between adjacent CJK characters when persisting slash-command
descriptions. Our locally-serialized desired descriptors keep the original
whitespace, so commandsEqual returned false on every startup for any
deployment with multi-line or CJK-heavy descriptions.
This caused reconcile to issue a PATCH for every such command on every
gateway restart. Under Discord's per-application rate limit that quickly
produced a burst of 429s and some commands silently failed to register
until the next restart — a recurring symptom behind several Discord deploy
429 reports (#75341, #75888).
Fix: apply the same two normalizations to description strings in
comparableCommand — collapse runs of whitespace to a single space, then
drop whitespace between CJK boundary characters — before JSON-based
equality. This mirrors Discord's storage semantics so round-tripped
descriptions compare equal.
Adds command-deploy.test.ts with regression coverage for:
- server-side default fields ignored (dm_permission, nsfw, version, ids)
- required:false treated as absent (existing behavior)
- CJK descriptions with \n separators normalized
- mixed CJK/ASCII descriptions with consecutive whitespace
- substantive description diffs still flagged
- ASCII whitespace normalization
* fix(discord): normalize localized command descriptions
* fix(discord): ignore null localization maps in command reconcile
---------
Co-authored-by: Peter Steinberger <steipete@gmail.com>
Peter Steinberger