hermes - ✅(Solved) Fix Discord slash command sync times out by recreating unchanged commands [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
NousResearch/hermes-agent#17157Fetched 2026-04-29 06:37:00
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Author
Participants
Timeline (top)
labeled ×4commented ×1cross-referenced ×1

Discord slash-command sync can time out because the safe sync diff treats Discord-populated integration_types as a Hermes-managed change.

Root Cause

Discord slash-command sync can time out because the safe sync diff treats Discord-populated integration_types as a Hermes-managed change.

Fix Action

Fixed

PR fix notes

PR #17159: Fix Discord slash sync default diff

Description (problem / solution / changelog)

Fixes #17157

Summary

This fixes Discord slash-command safe sync repeatedly recreating unchanged commands when Discord returns server-filled integration_types for commands whose desired Hermes payload omits that field.

Root Cause

Hermes compares canonical current command payloads with desired command payloads before deciding whether to edit, recreate, create, or delete commands. Discord returns integration_types for existing global commands even when the desired command from discord.py does not set it. In the live path, discord.py surfaced the server default as [0]; in direct REST triage, the raw payload surfaced another default shape. Because Hermes does not manage this field, the comparison treated all managed commands as metadata mismatches and tried to delete/upsert the full command set on every gateway startup. That mutation storm could exceed the startup sync timeout.

Changes

  • Normalize server-filled integration_types out of the current payload when the desired Hermes payload omits it.
  • Keep the existing safe-sync behavior for fields Hermes actually manages.
  • Add DISCORD_COMMAND_SYNC_TIMEOUT so deployments can tune the timeout without code edits.
  • Add a regression test for both observed default integration_types shapes.
  • Add a read-only scripts/discord-slash-sync-doctor.py helper that builds desired commands, fetches registered Discord commands, and prints the dry-run mutation plan.

Validation

  • python -m pytest tests/gateway/test_discord_connect.py -q
  • python -m py_compile gateway/platforms/discord.py tests/gateway/test_discord_connect.py scripts/discord-slash-sync-doctor.py
  • Ran the doctor against a live Discord application before/after cleanup: final plan was 35 desired, 35 existing, 35 unchanged, and no pending mutations.
  • Restarted a live gateway with slash sync enabled: it reconciled successfully with unchanged=35 updated=0 recreated=0 created=0 deleted=6 instead of timing out.

Changed files

  • gateway/platforms/discord.py (modified, +45/-3)
  • scripts/discord-slash-sync-doctor.py (added, +158/-0)
  • tests/gateway/test_discord_connect.py (modified, +73/-0)
RAW_BUFFERClick to expand / collapse

Summary

Discord slash-command sync can time out because the safe sync diff treats Discord-populated integration_types as a Hermes-managed change.

What we encountered

On a live Hermes gateway, startup repeatedly logged slash command sync timeouts. Direct Discord REST reads were fast, but the safe sync plan wanted to recreate every managed command. The commands were semantically unchanged; the only persistent mismatch was integration_types on the server-side command payload.

Raw REST and discord.py expose this default slightly differently, but Hermes does not currently set or manage integration_types in its desired command payload. Comparing it directly makes every command look changed and triggers a delete/upsert storm on startup.

Fix direction

When the desired payload omits integration_types, normalize the server-side value out before comparing current vs desired commands. This keeps safe sync focused on fields Hermes actually manages.

I have a PR ready with:

  • normalization for Discord-filled integration_types
  • a regression test covering both default shapes observed during triage
  • a read-only slash-sync doctor script for future debugging

extent analysis

TL;DR

Normalizing the server-side integration_types value before comparing current vs desired commands is likely to fix the Discord slash-command sync timeout issue.

Guidance

  • Identify the fields that Hermes actually manages and exclude integration_types from the comparison to prevent unnecessary delete/upsert operations.
  • Review the PR with normalization for Discord-filled integration_types and regression test to ensure it covers both default shapes observed during triage.
  • Consider using the read-only slash-sync doctor script for future debugging to quickly identify similar issues.
  • Verify that the normalization fix does not introduce any unintended side effects on command synchronization.

Example

No code snippet is provided as the issue does not contain sufficient code context, but the PR with normalization for Discord-filled integration_types should be reviewed for implementation details.

Notes

This fix assumes that integration_types is not a critical field for Hermes-managed commands and that normalizing it out will not affect command functionality.

Recommendation

Apply the workaround by normalizing the server-side integration_types value, as it directly addresses the identified cause of the issue and a PR with the necessary changes is already available.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING