Bug fix to allow the calls to webhook APIs to succeed when using GuildThread.

[AraHaan]

This fixes a bug where when using classes based on GuildThread (ones that most likely inherits from it), because GuildThread inherits from TextGuildChannel the inherited CreateWebhookAsync and the GetChannelWebhooksAsync methods would pass in only the Id (which for normal channels works), but for threads this would always fail as the thread Id would be used as a channel Id and Discord's API does not consider them to be valid channels. As such it is better to attempt to use ParentId (if not null), otherwise use Id (if ParentId is null).

[KubaZ2]

That is more like a Discord API quirk and I am not sure invoking these methods for the thread parent is a good idea. It introduces a confusing behavior and moves logic to autogenerated methods.

[jedrek0429]

Well, maybe this method simply shouldn't exist on channels where it would always return 404 and instead of introducing logic for passing the parent ID within NetCord, the developer can decide on what to do (notice the method doesn't exist and use it explicitly on the parent channel).

[KubaZ2]

Well, maybe this method simply shouldn't exist on channels where it would always return 404 and instead of introducing logic for passing the parent ID within NetCord, the developer can decide on what to do (notice the method doesn't exist and use it explicitly on the parent channel).

Since GuildThread is TextGuildChannel, it is not possible for it not to have these methods. Of course it would be possible to introduce some different structure but there are so many cases that I doubt it would make sense, but maybe? Also there are always methods that will fail in some cases, for example channel modification requires a certain permission, an 404 error for a specific channel type is not an real issue but I agree it would be better if it didn't happen.

A few years ago I had an idea of flattening the channel structure into just something like

class Channel;
class GuildChannel : Channel;

I think it would make the structure clearer but at the same time it would introduce lots of null/useless property values and basically every channel would have all possible channel-related methods so it would only make this issue worse.

[jedrek0429]

Currently webhook aliases are generated for TextGuildChannel, which means they are also available on GuildThread through inheritance, even though Discord threads cannot use webhooks.

I think the cleanest solution is to split the shared “text guild channel” surface from the “supports webhooks” capability.

Proposed structure:

public interface IPartialTextGuildChannel : IGuildChannel, INamedChannel
{
    // Shared text guild channel members
    // excluding webhook-related aliases/capabilities
    // (or other capabilities not available for threads)
}
public interface IWebhookChannel : IEntity
{
}

Then:

public class TextGuildChannel
    : TextChannel, IPartialTextGuildChannel, IWebhookChannel, ...
{
}
public class GuildThread
    : TextChannel, IPartialTextGuildChannel, ...
{
}

Webhook aliases would target IWebhookChannel:

[GenerateAlias([typeof(IWebhookChannel)], nameof(IEntity.Id))]

while all shared text-channel aliases would target IPartialTextGuildChannel.

This avoids accidentally exposing unsupported webhook APIs on threads while still preserving the common text-channel surface. This could be extended to other functionality that is limited by threads, but I'm not knowledgeable about this enough to mention all of it here.