[Bug]: BASE_TYPE_REQUIRED: This field is required' when calling `RegisterCommandsGloballyAsync`

[TheBoxyBear]

Check The Docs

• I double checked the docs and couldn't find any useful information.

Verify Issue Source

• I verified the issue was caused by Discord.Net.

Check your intents

• I double checked that I have the required intents.

Description

As of today, registering a bot with a single module fails with the server responding error code 50035 BASE_TYPE_REQUIRED: This field is required' which from reading forums, seems to be from either using the wrong post/put or not specifying application/json in the header. The same bot worked a few days ago on the same package version, so it appears to be related to a recent change in Discord's API.

The log does show some errors and warnings, but these same ones were being shown previously.

Although the project is setup to use Docker, the same issue happens regardless or running locally or as a container.

Fond workaround: Wrap the call in an empty try-catch. The commands seem to be still be registering with Discord despite the exception, and it allows the bot to keep running to respond to commands.

Version

3.18.0

Working Version

3.18.0

Logs

Discord.Net v3.18.0 (API v10)
Connecting
You're using the GuildScheduledEvents gateway intent without listening to any events related to that intent, consider removing the intent from your config.
You're using the GuildInvites gateway intent without listening to any events related to that intent, consider removing the intent from your config.
Connected
Error handling Dispatch (GUILD_AVAILABLE)

Sample

Ready to send this snippet Program.cs - Using DI based on the docs

using Microsoft.Extensions.DependencyInjection;

using Discord;
using Discord.WebSocket;
using Discord.Interactions;

using MyNamespace;

const string token = "[redacted]";

IServiceProvider _services = CreateProvider();
DiscordSocketClient _client = _services.GetRequiredService<DiscordSocketClient>();

_client.Log += Log;
_client.Connected += () => Task.CompletedTask;
_client.Ready += async () => await _services.GetRequiredService<InteractionHandler>().Start();

await _client.LoginAsync(TokenType.Bot, token);
await _client.StartAsync();

while (Console.Read() != 'q') ;

static IServiceProvider CreateProvider()
    => new ServiceCollection()
    .AddSingleton<DiscordSocketConfig>()
    .AddSingleton<DiscordSocketClient>()
    .AddSingleton(x => new InteractionService(x.GetRequiredService<DiscordSocketClient>()))
    .AddSingleton<InteractionHandler>()
    .BuildServiceProvider();

static Task Log(LogMessage message)
{
    Console.WriteLine(message.Message);
    return Task.CompletedTask;
}

InteractionHandler.cs - Mostly based on the docs, throws the exception in Start()

using Discord;
using Discord.Interactions;
using Discord.WebSocket;

using System.Reflection;

namespace MyNamespace;

// Primary constructor receiving args from DI
public class InteractionHandler(DiscordSocketClient client, InteractionService handler, IServiceProvider services)
{
    public async Task Start()
    {
        client.InteractionCreated += HandleInteraction;

        await handler.AddModulesAsync(Assembly.GetExecutingAssembly(), services);

        // EXCEPTION HERE - Work around by wrapping in an empty try-catch
        await handler.RegisterCommandsGloballyAsync();
    }

    private async Task HandleInteraction(SocketInteraction interaction)
    {
        // Copied snippet from docs
        try
        {
            // Create an execution context that matches the generic type parameter of your InteractionModuleBase<T> modules.
            var context = new SocketInteractionContext(client, interaction);

            // Execute the incoming command.
            IResult result = await handler.ExecuteCommandAsync(context, services);

            // Due to async nature of InteractionFramework, the result here may always be success.
            // That's why we also need to handle the InteractionExecuted event.
            if (!result.IsSuccess)
                switch (result.Error)
                {
                    case InteractionCommandError.UnmetPrecondition:
                        // implement
                        break;
                    default:
                        break;
                }
        }
        catch
        {
            // If Slash Command execution fails it is most likely that the original interaction acknowledgement will persist. It is a good idea to delete the original
            // response, or at least let the user know that something went wrong during the command execution.
            if (interaction.Type is InteractionType.ApplicationCommand)
                await interaction.GetOriginalResponseAsync().ContinueWith(async (msg) => await msg.Result.DeleteAsync());
        }
    }
}

TestModule - Basic module based on the docs

using Discord.Interactions;

namespace MyNamespace;

public class TestModule : InteractionModuleBase<SocketInteractionContext>
{
    [SlashCommand("echo", "Echo an input")]
    public async Task Echo(string input)
    {
        await RespondAsync(input);
    }
}

Packages

Microsoft.DotNet.ILCompiler
Microsoft.Extensions.Dependencyinjection

• Included with Docker template
  Microsoft.Extensions.Dependencyinjection
  Microsoft.NET.ILink.Tasks
  Microsoft.VisualStudio.Azure.Containers.Tools.Targets

Environment

• OS: Windows 11 24H2
• Architecture: AMD64
• SDK: .NET 9.0.306

[Misha-133]

Hey
a few things to mention here

The commands seem to be still be registering with Discord despite the exceptio

that is likely an incorrect observation. Commands do not disappear once registered, unless they get overriden. If they sucessfully register once - they will stay available even if the method fails.

The actuall issue here is likely the Error handling Dispatch (GUILD_AVAILABLE). It fails to deserialize something in the guild object in your case. Try changing the Console.WriteLine(message.Message); line in the Log event handler to print message.ToString() instead, as that will also then log the actual exception (or log the message.Exception's stacktrace).

Please post the stacktrace here once you obtain it

[TheBoxyBear]

I discovered the commands do stay registered as the bot can respond to commands even if the line is commented out. However, wrapping in a try-catch also allows changes to commands to be reflected on the client side, even if the method throws an exception.

Here is the full log. There seems to be a culture-related error. My pc was and still set to English (Canada)

13:47:44 Discord     Discord.Net v3.18.0 (API v10)
13:47:45 Gateway     Connecting
13:47:47 Gateway     You're using the GuildScheduledEvents gateway intent without listening to any events related to that intent, consider removing the intent from your config.
13:47:47 Gateway     You're using the GuildInvites gateway intent without listening to any events related to that intent, consider removing the intent from your config.
13:47:47 Gateway     Connected
13:47:47 Gateway     Error handling Dispatch (GUILD_AVAILABLE):
System.Globalization.CultureNotFoundException: Only the invariant culture is supported in globalization-invariant mode. See https://aka.ms/GlobalizationInvariantMode for more information. (Parameter 'name')
en-US is an invalid culture identifier.
   at System.Globalization.CultureInfo..ctor(String name, Boolean useUserOverride)
   at Discord.WebSocket.SocketGuild.Update(ClientState state, Guild model)
   at Discord.WebSocket.SocketGuild.Update(ClientState state, ExtendedGuild model)
   at Discord.WebSocket.DiscordSocketClient.ProcessMessageAsync(GatewayOpCode opCode, Nullable`1 seq, String type, Object payload)
13:47:58 Gateway     Ready

[Misha-133]

Well, dnet requires you to have globalization invariant mode disabled.
You have likely enabled it. https://learn.microsoft.com/en-us/dotnet/core/runtime-config/globalization#invariant-mode

[TheBoxyBear]

Not sure where that would be enabled, I don't have any files in the likes of runtimeconfig. This is also a regression from a few days ago using the same project.

[TheBoxyBear]

There's also no mention of locales in the csproj files.

Removed it, testing.

[TheBoxyBear]

The error persists after removing it from the project file.

[Misha-133]

Try explicitly setting it to false

<InvariantGlobalization>false</InvariantGlobalization>

[TheBoxyBear]

Try explicitly setting it to false

false

Still getting the exception.

[Misha-133]

Well that implies you have it enabled still somehow
It can be set by the environment variable. You can check for it in the terminal

echo $DOTNET_SYSTEM_GLOBALIZATION_INVARIANT

or check in the

var envVars = Environment.GetEnvironmentVariables();

Maybe it's being set by the IDE

[TheBoxyBear]

There's no environment variable related to globalization.

[Misha-133]

Well i'm kind of out of ideas then.
Pretty much the only reason for this exception to be thrown is globalization ivariant mode being enabled. While it is the default is some linux distros (and in docker containers) - it's pretty much never the case on bare windows.

[TheBoxyBear]

It may be related to having it once ran it as a container. I'll get in touch with someone on my team to run it fresh on their machine.

[d4n3436]

Well, dnet requires you to have globalization invariant mode disabled. You have likely enabled it. https://learn.microsoft.com/en-us/dotnet/core/runtime-config/globalization#invariant-mode

This isn't true though. DNet only uses CultureInfo on the user/server locale on interactions and invariant globalization mode can be safely used.
You need to set another MSBuild property to false, PredefinedCulturesOnly.