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

Event (GUILD_MEMBER_UPDATE) doesn't update for automatic timeout removals #4269

Closed
GoldenAngel2 opened this issue Dec 21, 2021 · 3 comments
Closed
Labels

Comments

@GoldenAngel2
Copy link
Contributor

Description
When the timeout automatically ends it doesn't send a GUILD_MEMBER_UPDATE event.

Steps to Reproduce

  1. Listen to the event
  2. Timeout a test account
  3. Wait for it to automatically end.
  4. The event doesn't fire

Expected Behavior
To send communication_disabled_until: null when the timeout automatically ends.

Current Behavior
It doesn't fire the event.

Client and System Information
API: v9
Gateway: v9

Note
The event does fire for when someone manually removes the user/bot from timeout

@hemu
Copy link
Contributor

hemu commented Dec 22, 2021

the reason this is happening is because we don't go out of our way to change the communication_disabled_until field once the timeout naturally expires, so there is no update. We let the value continue to be the existing datetime which is now in the past, and since the user is only timed out until the communication_disabled_until value, a datetime in the past means no longer timed out

@ckohen
Copy link
Contributor

ckohen commented Dec 22, 2021

This makes sense on the client side, it makes logging for bots much more involved though. There is no audit log entry on timeout expiry, and there's no event, so we basically have to track the timeouts manually like we did when we did it with roles. I wouldn't necessarily consider this a bug, but I would like this to be changed or rectified in some other manner.

@hemu
Copy link
Contributor

hemu commented Dec 22, 2021

yea I agree the current implementation doesn't allow for the best dev experience for those of you who want to be able to react to timeout expirations easily. Realistically based on what would be involved here and current priorities for the timeout feature, I am pretty sure support for this use case won't be offered any time soon, sorry :( but we'll note this as a use case that some devs want and consider this for the future

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

No branches or pull requests

4 participants