handle crashes for DM commands

[HurricanKai]

It seems like because handle always expects a guild_id, which in DMs does not exist, an application command will never work in DMs.

Thanks for the work, this is really nice to use 😄

(I might make a PR for this if I get the time, but don't hold your breath, I just noticed this during debugging, it's not really necessary for me either)

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

✅ Successfully generated implementation plan.

💡 Use @coderabbitai <feedback> to replan

Examples

• Example 1
• Example 2

---

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord or schedule a call!

[coderabbitai]

Coding Plan

Approach

The library currently doesn't support commands that work in both guild contexts and DMs. This implementation adds a register_globally: true option to the command DSL that allows commands to be registered both globally (for DM support) and per-guild (for fast updates), enabling dual-context command availability.

Observations

This is an Elixir library for Discord Interactions that provides a DSL for defining application commands, handlers, and components. Commands are registered either globally (available everywhere including DMs) or per-guild (fast updates but guild-only). The library uses a macro-based DSL in lib/discord_interactions.ex for command definitions, handles registration in lib/discord_interactions/command_registration.ex, and already has separate handle/1 function clauses for interactions with and without guild_id. The current limitation is that commands must be exclusively global OR guild-specific, preventing developers from having commands work in both contexts simultaneously.

Assumptions

Assumption 1: How should commands be designated for dual registration (both global and per-guild)?

Options Considered:

• Add a register_globally: true option to the application_command macro that can be used alongside guild() calls
• Add a new global() macro that can be used in combination with guild() macros
• Automatically register all guild commands globally by default

Chosen Option: 1

Rationale: Adding register_globally: true is most explicit, aligns with the existing options-based API pattern in the DSL, and maintains backward compatibility by making this an opt-in feature.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Extend Command DSL for Dual Registration

Enable commands to be marked for both global and guild-specific registration through the DSL.

Task 1: Add global registration option to command metadata

• Add register_globally field to the command configuration structure that gets built up during macro expansion
• Update the application_command macro in lib/discord_interactions.ex to accept and store the register_globally: boolean option
• Set default value to false to maintain backward compatibility (existing guild commands won't automatically become global)
• Ensure this option is captured in the command metadata alongside existing fields like name, description, options, and guilds list

Task 2: Update command metadata propagation

• Ensure the register_globally flag is preserved through the DSL macro expansion pipeline
• Verify that command metadata passed to registration logic includes this new field
• Update any command metadata structure documentation or typespecs to reflect the new field

🤖 Prompt for AI agents

Extend the command DSL to support dual registration by adding a
`register_globally` option.

In `lib/discord_interactions.ex`:
- Add `register_globally` field to the command configuration structure
- Update the `application_command` macro to accept and store the
`register_globally: boolean` option (default: `false`)
- Ensure the flag is captured in command metadata alongside name, description,
options, and guilds list
- Preserve the `register_globally` flag through the DSL macro expansion pipeline
- Update command metadata structure documentation or typespecs to include the
new field

Phase 2: Implement Dual Command Registration

Modify the command registration logic to support registering commands in both global and guild contexts.

Task 1: Update command categorization logic

• Modify the command categorization in lib/discord_interactions/command_registration.ex within the register_commands/1 function
• Change the current if/else logic that places commands exclusively in either global_commands or guild_commands
• When a command has both guilds list AND register_globally: true, add it to both maps:
  • Add to global_commands map with command name as key
  • Add to guild_commands map with {guild_id, command_name} tuples for each guild
• Maintain existing behavior when register_globally is false or absent (guild commands stay guild-only, commands without guilds are global-only)

Task 2: Execute dual registration with Discord API

• Update the registration flow to call both bulk_overwrite_global_commands and register_guild_command when appropriate
• Ensure commands marked with register_globally: true are included in the global commands list sent to Discord
• Verify that the same command definition is used for both global and guild registrations (same options, description, etc.)
• Handle any registration errors appropriately for both contexts

🤖 Prompt for AI agents

Implement dual command registration to support both global and guild contexts
simultaneously.

In `lib/discord_interactions/command_registration.ex`:
- Modify command categorization in `register_commands/1` function
- Update the if/else logic to allow commands in both `global_commands` and
`guild_commands` maps
- When a command has both `guilds` list AND `register_globally: true`, add it to
both:
  - Add to `global_commands` map with command name as key
- Add to `guild_commands` map with `{guild_id, command_name}` tuples for each
guild
- Maintain backward compatibility: when `register_globally` is false/absent,
keep existing behavior
- Update registration flow to call both `bulk_overwrite_global_commands` and
`register_guild_command` for dual-registered commands
- Ensure same command definition is used for both global and guild registrations
- Handle registration errors appropriately for both contexts

Phase 3: Add Test Coverage for DM Scenarios

Add comprehensive test coverage for command handling in DM contexts.

Task 1: Create DM interaction test fixtures

• Create test interaction payloads in test/discord_interactions/ that simulate DM contexts (interactions without guild_id field)
• Include application command interactions, autocomplete interactions, and component interactions
• Ensure test fixtures match the actual Discord API structure for DM interactions as confirmed by web search results

Task 2: Add DM command handling tests

• Add test cases in test/discord_interactions/plug/handle_request_test.exs for commands invoked in DMs
• Test scenario where a command is registered globally and invoked in a DM (should succeed)
• Test scenario where a command is registered only per-guild and invoked in a DM (should fail gracefully)
• Test scenario where a command is registered in both contexts (dual registration) and verify it works in both guilds and DMs
• Verify that the handle function's pattern matching correctly routes DM interactions to global_commands map

Task 3: Add dual registration test coverage

• Add tests in test/discord_interactions/command_registration_test.exs (or create if it doesn't exist) for the dual registration logic
• Verify commands with register_globally: true appear in both global and guild command maps after registration
• Test that the registration makes appropriate API calls to both global and guild endpoints
• Ensure backward compatibility: commands without register_globally option behave as before

🤖 Prompt for AI agents

Add comprehensive test coverage for DM scenarios and dual registration
functionality.

Create DM interaction test fixtures in `test/discord_interactions/`:
- Create test payloads simulating DM contexts (interactions without `guild_id`
field)
- Include application command, autocomplete, and component interactions
- Match actual Discord API structure for DM interactions

Add tests in `test/discord_interactions/plug/handle_request_test.exs`:
- Test globally registered command invoked in DM (should succeed)
- Test guild-only command invoked in DM (should fail gracefully)
- Test dual-registered command works in both guilds and DMs
- Verify handle function pattern matching routes DM interactions to
global_commands map

Add tests in `test/discord_interactions/command_registration_test.exs`:
- Verify commands with `register_globally: true` appear in both global and guild
command maps
- Test registration makes appropriate API calls to both endpoints
- Ensure backward compatibility: commands without `register_globally` behave as
before

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Extend the command DSL to support dual registration by adding a
`register_globally` option.

In `lib/discord_interactions.ex`:
- Add `register_globally` field to the command configuration structure
- Update the `application_command` macro to accept and store the
`register_globally: boolean` option (default: `false`)
- Ensure the flag is captured in command metadata alongside name, description,
options, and guilds list
- Preserve the `register_globally` flag through the DSL macro expansion pipeline
- Update command metadata structure documentation or typespecs to include the
new field
===============================================================================

Task: 2

Implement dual command registration to support both global and guild contexts
simultaneously.

In `lib/discord_interactions/command_registration.ex`:
- Modify command categorization in `register_commands/1` function
- Update the if/else logic to allow commands in both `global_commands` and
`guild_commands` maps
- When a command has both `guilds` list AND `register_globally: true`, add it to
both:
  - Add to `global_commands` map with command name as key
- Add to `guild_commands` map with `{guild_id, command_name}` tuples for each
guild
- Maintain backward compatibility: when `register_globally` is false/absent,
keep existing behavior
- Update registration flow to call both `bulk_overwrite_global_commands` and
`register_guild_command` for dual-registered commands
- Ensure same command definition is used for both global and guild registrations
- Handle registration errors appropriately for both contexts
===============================================================================

Task: 3

Add comprehensive test coverage for DM scenarios and dual registration
functionality.

Create DM interaction test fixtures in `test/discord_interactions/`:
- Create test payloads simulating DM contexts (interactions without `guild_id`
field)
- Include application command, autocomplete, and component interactions
- Match actual Discord API structure for DM interactions

Add tests in `test/discord_interactions/plug/handle_request_test.exs`:
- Test globally registered command invoked in DM (should succeed)
- Test guild-only command invoked in DM (should fail gracefully)
- Test dual-registered command works in both guilds and DMs
- Verify handle function pattern matching routes DM interactions to
global_commands map

Add tests in `test/discord_interactions/command_registration_test.exs`:
- Verify commands with `register_globally: true` appear in both global and guild
command maps
- Test registration makes appropriate API calls to both endpoints
- Ensure backward compatibility: commands without `register_globally` behave as
before

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- @coderabbitai You can skip phase 3. Add a simple unit test case for phase 2.
- @coderabbitai For assumption 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!

[dhrdlicka]

Hi, thanks for opening this issue! I tried reproducing this by adding properties(%{contexts: [0, 1, 2]}) to the application commands to enable them to work in DM contexts and that seemed to work fine. The library does try to match against guild ID in order to handle server-local commands, and there is a fallback for when there isn't one in the interaction data, so I am not fully sure if that is indeed the problem.

Would it be possible to share how are you setting up the command, so I could troubleshoot this further?