Skip to content

feat: update cooldown handling to support async operations #2823

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

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

Lumabots
Copy link
Contributor

@Lumabots Lumabots commented Jun 28, 2025

Summary

it add the possibility to use async function for cooldown, it also change the internal function to use ctx instead of only message since slash commands dont have a message
Nothing should be breaking

Information

  • This PR fixes an issue.
  • This PR adds something new (e.g. new method or parameters).
  • This PR is a breaking change (e.g. methods or parameters removed/renamed).
  • This PR is not a code change (e.g. documentation, README, typehinting,
    examples, ...).

Checklist

  • I have searched the open pull requests for duplicates.
  • If code changes were made then they have been tested.
    • I have updated the documentation to reflect the changes.
  • If type: ignore comments were used, a comment is also left explaining why.
  • I have updated the changelog to include these changes.

@Lumabots Lumabots requested a review from a team as a code owner June 28, 2025 14:17
@pullapprove4 pullapprove4 bot requested a review from ChickenDevs June 28, 2025 14:17
@Lumabots Lumabots changed the title fix: update cooldown handling to support async operations feat: update cooldown handling to support async operations Jun 28, 2025
… + correct typehint of max_concurrency since only ctx is passed and never message
@Lumabots
Copy link
Contributor Author

@Soheab brought to my attention that this PR might be breaking — specifically, the renaming of the message parameter to ctx could cause issues if someone is using a message cooldown, like with get_bucket(message=message).
Screenshot 2025-06-29 at 16 39 41

If they’re not using get_bucket(message=...), then there shouldn’t be any problems, since both message and ctx share all the internal attributes being accessed.

That said, I’m personally against keeping the parameter named message, especially since slash commands don’t even have a message attribute.

Let me know how you’d like to handle it. I don’t think this should be an issue — using ctx instead of message shouldn’t break anything unless a user is specifically calling that function, which I doubt many people do.

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

Successfully merging this pull request may close these issues.

1 participant