Skip to content

fix: error in voice (or thread ?) text channel#4

Merged
Bilal2453 merged 3 commits intoBilal2453:mainfrom
Ta-noshii:patch-1
May 19, 2024
Merged

fix: error in voice (or thread ?) text channel#4
Bilal2453 merged 3 commits intoBilal2453:mainfrom
Ta-noshii:patch-1

Conversation

@Ta-noshii
Copy link
Copy Markdown
Contributor

Update Interaction.lua to not error when trying to save a new message in voice (and thread?) text channels because channel parent doesn't exist

Update Interaction.lua to not error when trying to save a new message in voice (and thread?) text channels because channel parent doesn't exist
@Bilal2453
Copy link
Copy Markdown
Owner

This is a breaking change, this method can only be returning a Message object or an error tuple. data is not a Message object though.
This problem cannot be solved sadly without having support for those channels, the best option to make it not crash here is to return an error tuple, or simply tell user to not respond to interactions in those channels.

Any other ideas?

@Ta-noshii
Copy link
Copy Markdown
Contributor Author

Ta-noshii commented Apr 11, 2023

The thing is, everything worked fine, the interaction got responded to and stuff though only when it tries to log the new message in the channel it errors. So we should either as you said fully implement support for those channels or check the channel type when trying to put the message in the cache (I assume that's what its doing) and act accordingly
(Btw, we cant check the channel type using .channel/._channel since its nil)

@Bilal2453
Copy link
Copy Markdown
Owner

Bilal2453 commented Apr 11, 2023

I am aware it works just fine, but errors when trying to construct a message object. We don't have to check the channel type at all, just check if _channel is nil, and if it is do return nil, "Failed to construct a Message object".

The side effect of this is that you cannot tell when the interaction has actually succeeded but failed to construct the message object on client side, or if it legit failed at Discord side. Users can still match for the returned error message I guess, really not cool :(

Discordia is currently accepting similar PRs, so we may want to look into something like SinisterRectus/Discordia#355.

@Bilal2453
Copy link
Copy Markdown
Owner

I guess technically we also have another solution, simply ignore any Interaction received with no _channel, i.e. do not emit interactionCreate for it. I would rather not do this though.

Or alternatively, we could also do the same as above, but instead of checking for _channel after making the request, we could make _sendFollowup fail before createWebhookMessage.

@Bilal2453
Copy link
Copy Markdown
Owner

@Ta-noshii For now, you can ignore all interactions that does not have a channel object to prevent your bot from crashing, that is, do not :reply to any Interaction that has Interaction.channel/Interaction._channel nil.

@Bilal2453 Bilal2453 merged commit a9be099 into Bilal2453:main May 19, 2024
@Bilal2453
Copy link
Copy Markdown
Owner

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants