Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GUILD_AUDIT_LOG_ENTRY_CREATE payload API versioning issues #6493

Closed
Misha-133 opened this issue Oct 19, 2023 · 3 comments
Closed

GUILD_AUDIT_LOG_ENTRY_CREATE payload API versioning issues #6493

Misha-133 opened this issue Oct 19, 2023 · 3 comments
Labels
bug synced Synced to internal tracker

Comments

@Misha-133
Copy link
Contributor

Misha-133 commented Oct 19, 2023

Description

Audit log entiries sent to bots on the GUILD_AUDIT_LOG_ENTRY_CREATE event come in format, that matches the API version of the app that caused the event, not the version the app that recieves the event uses.

I've encountered this with audit log entries of type 10, 12, 13, 14 & 15, but this might extend to other ones.

Steps to Reproduce

  1. Have an app connected to gateway with the GUILD_MODERATION intent enabled; App should run on API v10
  2. Execute an action that involves creating/updating/deleting channel permission overwrites with a rest call to API v6 (ex. delete a channel with permission overwrites)
  3. Watch the payload of the GUILD_AUDIT_LOG_ENTRY_CREATE have permission overwrites in API v6 format

Expected Behavior

The payload of GUILD_AUDIT_LOG_ENTRY_CREATE should be in format of the API version the app that recieves the event uses.

Current Behavior

The payload of GUILD_AUDIT_LOG_ENTRY_CREATE comes in format of the API version the app that executes an action uses.

Screenshots/Videos

image
image
image

Client and System Information

  • Postman 10.19
  • Discord.Net 3.13 local dev build, API v10
@Misha-133 Misha-133 added the bug label Oct 19, 2023
@DV8FromTheWorld
Copy link
Member

Can confirm this bug exists.

@DV8FromTheWorld DV8FromTheWorld added the synced Synced to internal tracker label Oct 24, 2023
@DV8FromTheWorld
Copy link
Member

I have merged a fix for this. It will be out in the next day or two

@Misha-133
Copy link
Contributor Author

Yup, can confirm the type is a number now
allow_new & deny_new are still sent tho... but ig it's good enough 😅

Thanks for a quick fix

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug synced Synced to internal tracker
Projects
None yet
Development

No branches or pull requests

2 participants