Include permission overwrites in slash command channel entities

[QuantumToasted]

Might I precede this entire discussion with a simple question: Why is this not the case already? If the goal of slash commands is to promote stateless/less-state-reliant bots, why require an additional REST request just to fetch a channel with its overwrites?

We have a slash command which modifies a guild channel's overwrites - with a target channel option to modify. The resolved entities passed alongside the command interaction includes the target channel, obviously, but that model is missing some fields, in our specific case, permission overwrites. Thus, without an active cache of channels or an extra REST request to fetch the channel again, there is no way to view the overwrites for the supplied channel.

[advaith1]

Why is this not the case already?

it is not worth sending what could be a lot of data in every interaction when an insignificant amount of commands actually need the channel's whole list of permission overwrites.

[muddyfish]

It might be nice if we could specify the extra models we need when registering the command initially, which would help with cases like this.

[ckohen]

That's starting to lean towards graphql type systems, which works great....for a single dev. It's much harder to reliably represent the data that discord sends on a library level if that data is not consistent.

Don't get me wrong, I love the idea, but there's quite a few feasibility constraints that would hold this back right now.

[QuantumToasted]

it is not worth sending what could be a lot of data in every interaction

I'm a little confused by this. Not every interaction that's sent across the gateway is a slash command interaction, and not every slash command interaction is for a command that specifically contains a (resolved) channel entity. I completely understand the concern about sending extra/unnecessary data across the gateway, but this could be said for a lot of events in general. I can't imagine that the vast majority of commands involve channel options.

This isn't a make or break problem for me personally - I can workaround this by using the bot's already-existing gateway connection to get the channel from cache. It just presents a problem to potential slash command bot users utilizing the non-gateway method of handling slash commands who wish to view more information for the channel (in this case, overwrites - I may not know what other information is not returned for channel entities here) - requiring a gateway connection, or an additional REST request for commands that require that information.