-
Notifications
You must be signed in to change notification settings - Fork 23
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
User Suspension Tracker: fix bug that does not retrieve the suspensions correctly #1265
Comments
But doesn't staff review the user even if the request is denied? Or do they review only the specific not activated / multiple wins reported in the ticket? |
Actually I have no idea what exactly they do. One even once wrote that the suspension was already served but re-rolled anyways. So... yeah. No idea how they do it. The problem I see is that a re-roll gets denied because there was already a suspension. Someone posts that ticket to your database and the information gets stored. |
While chatting with a supporter I took the chance to ask a few questions. I was told they have exact data about which suspension was served for which non-activated win/multiple win. |
But do they only check the specific win reported or all wins? For example, let's say a user has A, B and C not activated wins. I open a ticket reporting their A and B wins. Does support only check if the user has been suspended for A and B, or do they check for all wins (which includes C)? Because ESGST stores the date of the ticket, so if the user has new not activated / multiple wins, it will not show that the user has served suspension for them. Maybe I should store the date of the win instead. |
I would assume they check either all non-activated or all multiple wins, depending what you write in the support ticket, and compare all of the results with their data to see if there's one where no suspension was served for yet. I could ask again though. I see, so ESGST compares ticket dates and SGTools findings. I see. Good. Let me know if I should ask the supporter again. |
Well, if you could ask them if they check all wins that would be nice, because it would help me make sure that the dates are stored correctly. It doesn't make much sense for me if they only check specific wins. If a user is reported, why not just go ahead and check for all of their not activated / multiple to see which ones they haven't been suspended for yet? It's a lot more practical than waiting until another user submits a ticket about the other wins. |
Why not? Well, because it can take several minutes to the check just one user with ESGST (if that is what their using to check things). Considering all the tickets I could imagine that they only do the least necessary. |
ESGST uses SGTools directly, so SGTools can't be quicker than ESGST. |
It is. I'd assume ESGST gets stuck for some reason and therefore takes longer. In the last days I've many times simply closed the ESGST checker after several minutes and done it on the website much quicker. (Mostly for the multi key GAs but also a few times for single winner GAs.) They usually check both - non-activated and multiple wins. But that's not a guideline, more like a best practice when there's enough time to do it/not too many open tickets. |
Not possible, unless you are doing multiple checks at the same time, because ESGST limits that. SGTools has a cache, so re-running the check is a lot faster if someone already checked the user in the past few minutes. Ok, that's unfortunate, because I'll have to change how things are stored in the database. I assumed everything was always checked. But thanks for the info. |
Multiple checks as in using the checker to check all winners at once for mutli keys GAs? No problem. |
Can you give me the name of the user? You can do it privately if you want. If ESGST is taking longer to check a single user, with no other checks going on, then there is definitely a bug there. You might want to open an issue about it. |
Not one in specific. Basically it was all checks I did with my recent giveaways this last several days - on multi key and single key giveaway's winner pages. I'll have several more giveaways ending these days and will see how that goes. |
Ok, so I've checked the 4 winners of a multi-key giveaway and it took about 11 minutes! to check them all. While of all the people the (first) one was the guy with the most wins (over 1400), his check was done in "only" about 1.5 minutes. From there it only got worse: The second guy took 2m10s (713 wins), the third 2m35s (747 wins) and the last one took a whopping 4m33s (1141 wins). If you want me to open an issue for it, let me know. Or open it yourself, it wouldn't make a difference, I guess. (By the way, this first multi key check was an exemption in regards of how many games they have won. Even users like this typically don't take anything close that long to be checked.) Edit: Just did another 5 key GA winner check - it took about 17 minutes and 40 seconds. |
Yep, there's definitely an issue with the SGTools checker done with ESGST. I was just checking a single key GA winner and it took minutes without anything happening. So I opened SGTools in another tab to check him manually - which was finished in a timely manner as expected. |
I was able to look better at this issue today and it's not an issue. The tracker cannot know the type of the ticket or what is contained in it from the main tickets page, so it shows checkboxes for all tickets, but when the tickets are sent it selects only the relevant ones. You can see that when you opened the ticket, there was no button inside to send the ticket. So the only issue here is the SGTools check, which I haven't been able to reproduce. I told you how to inspect the background page of the extension in another issue, right? Could you open that page and see if a request is being made to SGTools immediately when checking a user? Because if it is, then the problem could be SGTools limiting the connection or something. |
Alright. Yes. I can take a look at that sometime when I'll have to check users. |
I'll hijack your issue for another issue, if you still have the SGTools issue please open a new issue. |
Description
According to the feature's description:
"You can only send tickets that belong to one of the accepted categories to the database:
Still I'm getting check-mark boxes for cases where I asked for a re-roll because the game was already owned ("Previously Won the Game, or Already on Account") although there's no suspension to report. (See screenshots.)
I'm also getting check-mark boxes for tickets where a re-roll was denied (because the suspension was already served).
Now the ticket itself and the comments below it unfortunately don't contain information on what exactly the reason for the already served suspension was (i.e. to which giveaway it was related to).
So since there can't really be any information be gained in regards of which non-activated or multiple times won giveaway this was about - apart from the sole fact that there was, at some point, a suspension, there's not much new to send to the database...
Well, therefore tracker info could be misleading in case a user already had a suspension, but since then has gotten new un-activated or mutliple wins.
Screenshots
System (please complete the following information):
The text was updated successfully, but these errors were encountered: