search

vhs / raffle

Raffle Bot to run raffles on VHS forums
1 stars 3 forks source link

fix: closing time override is broken #24

Open TyIsI opened 1 month ago

TyIsI commented 1 month ago

Quite literally right now. See #23.

This is in part due to @discourse/discourse.

My comments from the PR:

The override time used to be epoch.

Is the new time override timezone sensitive if the offset is forgotten? (I assume that it will default to UTC/Z.) Should that be documented more clearly? Should there be a fallback?

Or should be changed this into a Boolean and have that time automatically be printed with the post? Should we always have the "source"/close time post be printed on the winners post? Or if there's no closing time, should we get RaffleBot to post a timestamp on the topic that then can be used to redo/verify the poll?

Prefacing this with that it was broken to begin with and not intending to be annoying. There are a lot of ways that this can break if/when users are inconsistent and this would also require API keys while we're trying to get to use github actions.

That is to say, I think the raffle script/bot/action should always be the primary source of information and that the action should always be in charge of solving the issue.

I will check if I can open a ticket with discourse to get them to add registering poll closure on the post.

As a work-around, registering poll closure by the bot on the topic as soon as it sees the poll as closed would seem like the best solution.

And then the bot can calculate from that registered time, as can anyone who wants to verify it.

@robmackenzie @lukecyca opinions?

lukecyca commented 1 month ago

registering poll closure by the bot on the topic as soon as it sees the poll as closed would seem like the best solution

I disagree. It's critical that the time used for hash calculation be determined in advance. In the scenario where I forgot to set the poll to auto-close at a Friday night at midnight, then I just click "close" sometime early on Saturday morning. If the hashes get calculated based on that timestamp, then I can just choose an instant to close the poll that happens to create hashes that are to my advantage (I can try a bunch and wait for one that makes me a big winner!).

A better approach is to manually override the close time to be the time that was intended and specified when the raffle was launched. In this case, "2024-08-10 00:00:00" Vancouver time.

Is the new time override timezone sensitive if the offset is forgotten?

It's whatever python's datetime does by default. I made the example include the TZ offset. The same ambiguity exists when creating a poll in Talk. Is that UI widget in UTC? Vancouver time? browser's local time? This override syntax is less ambiguous than what we previously had.

Should we always have the "source"/close time post be printed on the winners post?

That's a good idea for an improvement, and would generally make it easier to verify and also to troubleshoot. That's only tangentially related to this issue though.

the action should always be in charge of solving the issue

Well I just shouldn't have forgotten to set the poll to auto-close! We're already talking about an override option which is an escape hatch for when something goes wrong. The default happy path will be for the GH action to run the script, and for all the parameters to be contained on the Talk post. When that fails (for any reason) then we can still fall back, run it manually, post it manually, and include the necessary parameters so that it's still provably untampered.