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

Add a command to count # of messages in a channel #100

Open
Cephian opened this issue Mar 30, 2022 · 2 comments
Open

Add a command to count # of messages in a channel #100

Cephian opened this issue Mar 30, 2022 · 2 comments
Labels
enhancement New feature or request

Comments

@Cephian
Copy link
Collaborator

Cephian commented Mar 30, 2022

To ease our worries about people messaging and going over cap. Add a command !count with optional parameter #channel which prints the number of messages in a channel, or "{MAXIMUM_MESSAGES_TO_SCAN}+" if the amount is more than MAXIMUM_MESSAGES_TO_SCAN

@Cephian Cephian added the enhancement New feature or request label Mar 30, 2022
@anoadragon453
Copy link
Owner

Hmm, I feel that if we have the ability to count the number of messages in a channel, we also have the ability to just pass that number to channel.history?

...I've also just read the documentation on history() and realised we can just set limit=None to scan the entire channel.

Alternatively, we could just set the limit to something improbably high, but not infinity. So that in case we do accidentally run !list on an archive channel, it would perhaps take about a minute to time out, rather than much longer.

I'm not sure if you've run this on any of the archive channels yet, but somewhat surprisingly the largest count of messages I can find among a small sample are <3K for the entire event:

image.

So perhaps we just want to stick with a limit, but one that's much higher than what could be reasonably sent in 15m?

@Cephian
Copy link
Collaborator Author

Cephian commented Apr 1, 2022

Alternatively, we could impose no limit on channel.history, but make !list interruptable by a new !list invocation. I don't think we ever really want Busty to not read the entire channel, our only fear is that we don't want a scan run "too early" to block us for too long.

Extra: We could also add a command to cancel an active list without starting a new one, since it would be simple if we implemented the cancellable !list, though I'm not sure what the use case would really be other than saving VPS resources or wanting to not invalidate the file cache over an accidental !list, neither of which are a situation I've been in.

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

Successfully merging a pull request may close this issue.

2 participants