Application command overloads

[Bluenix2]

Summary

An issue that many bot developers looking for zero downtime will run into is the 1-hour period it takes for Discord to roll out application command updates. In the event of a breaking change the developer has to either keep the old callbacks until the change has propagated or the new and be unable to use the old commands until the client receives the new.

The fix to this issue is application command overloading. With this feature, both the old and new callbacks can be deployed and the library will automatically match the correct callback.

Description

Scope

The point of this feature is not yet to allow dispatching different callbacks based on received arguments for the same command. Therefore, there is no guarantee in the order of how callbacks are tried because they're assumed to be incompatible so that there is no ambiguity.

Usage

In general there's two APIs that this can take depending on implementation details:

Registered application commands with the same name

The first alternative is that two or more callbacks are registered with the same name. This would make the overloading implicit:

from wumpy.interactions import InteractionApp, Option


app = InteractionApp(...)


@app.command(name='echo')
async def echo_old(interaction):
    await interaction.respond('*Echo...* *echo...*...')


@app.command(name='echo')
async def echo_new(
    interaction,
    message: str = Option(description='Message to echo back...')
):
    await interaction.respond(f'*{message}*')

The downside of this is that a new keyword-argument will have to be added which marks the primary command that gets synchronized and migrated.

.overload() decorator

The second option is a new decorator on an application command object that registers the overload. This alternative would fix the issue of marking the primary callback because the primary callback would be the original one:

from wumpy.interactions import InteractionApp, Option


app = InteractionApp(...)


@app.command(name='echo')
async def echo_old(interaction):
    await interaction.respond('*Echo...* *echo...*...')


@echo.overload()
async def echo_new(
    interaction,
    message: str = Option(description='Message to echo back...')
):
    await interaction.respond(f'*{message}*')

The downside to this depends on implementation details. If the application command object has to be re-created because the overload functionality is in another class then it would be poor code-architecture to have the application command object do this itself.

Tasks

• Add overloading functionality to existing application command objects
  • Alternatively, create a new class that has this functionality
• Write up tests ro ensure the correct callback is dispatched as would be expected
• Document overloading and how to roll out updated using this feature (see the documentation repository)