"service error" on available_drops check and claim operation since 14:00:00 GMT-3 #590
Comments
DevilXD
changed the title
|
Here's one of mine that I just got during claiming: Fatal error encountered:
Traceback (most recent call last):
File "main.py", line 155, in main
await client.run()
File "C:\...\TwitchDropsMiner\twitch.py", line 587, in run
await self._run()
File "C:\...\TwitchDropsMiner\twitch.py", line 648, in _run
await drop.claim()
File "C:\...\TwitchDropsMiner\inventory.py", line 259, in claim
result = await super().claim()
^^^^^^^^^^^^^^^^^^^^^
File "C:\...\TwitchDropsMiner\inventory.py", line 142, in claim
result = await self._claim()
^^^^^^^^^^^^^^^^^^^
File "C:\...\TwitchDropsMiner\inventory.py", line 158, in _claim
response = await self._twitch.gql_request(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\...\TwitchDropsMiner\twitch.py", line 1387, in gql_request
raise GQLException(response_json['errors'])
exceptions.GQLException: [{'message': 'service error', 'path': ['claimDropRewards']}]The claim did succeed, so I couldn't catch it happening, but the result of it was an error anyway. I'll need to investigate these further. I can't reproduce this for Lost Ark specifically, at least when I checked it just now. The AvailableDrops GQL hash hasn't changed for me (yet?). EDIT: It's been a while since the claim operation hash was updated, which could be the cause for this. If anyone would be able to get their hands on the updated hash (if it was updated), that'd be helpful. |
|
Happening for me as well, excluding Lost Ark works as a fix. |
|
Just to be sure, I've rechecked this on my side when the above message was about 20 minutes old, and haven't encountered an error - Lost Ark campaigns and channels loaded in just fine. Whatever causes the error, hasn't arrived to my Twitch account yet. It seems like Twitch is doing one of those gradual rollouts again, and thus some people are using the new version, while others are still on the old version. We need to wait. Based on the past events, all it takes to fix these is just a new AvailableDrops GQL hash, that would need to be grabbed by someone running the newer version. Either way, the rollouts usually last a day or two, sometimes three, so I'm going to get my hands on it eventually anyway. |
|
Seems I haven't completed the "Aegir Awakens" campaign for But this is just #415 again anyway, innit? |
Can you provide any methods to grab latest GQL hash? I may look into it |
|
@skmedix It's a tedious task of opening Twitch pages while having web developer tools open (F12 on most browsers). On the network calls tab, find the It's a bit advanced technical things. Doing all this requires some basic knowledge of how to use the web dev tools, as well as where to look for, and even what Twitch pages to open. "AvailableDrops" GQL call is made only when you open a stream (any channel will do), inventory and campaigns pages let you drop their respective hashes, claim drop GQL operation happens only during the claim process, so you need to catch the request when clicking on the claim button, and that requires some manual finishing mining of a drop (I'll try doing this later today or tomorrow). |
|
@DevilXD I only asked because I missed it the first time I looked (I didn't open a stream, but I directly went to the inventory). With a simple matcher it's actually super easy, and I can confirm that the hash for |
|
This has now started working again without Lost Ark in the exlusions list. |
|
Yeah, I've checked Lost Ark this morning again, and still no errors or other issues. It seems that the rollout was possibly reverted, due to the errors popping up. We'll need to monitor the situation though. |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Since this has stopped being an issue, I guess it can be closed now. |
|
Turns out it's back: #599. I'm reopening this one, to keep the discussion up. |
|
tldr: Had to block |
|
The annoying part of this is that the bulk check logic specifically batches requests together. That means that, even if I would add any kind of logging to this, it'd narrow it down to up to 20 channels. Rectifying the error is also hard to do, given that the The only thing I can think of here, would be to rework the |
|
#600 points towards 40+ games being tracked as mining candidates, as the source of the error. To be fair, I've never imagined someone would actively be playing (and want drops for) that many games at the same time, I'm not sure if it's even possible time-wise to keep up with the campaigns, even if running the miner 24/7. As a temporary mitigation for anyone affected, I'd suggest trimming down your priority lists, and excluding games you care the least about. Also, anyone affected should comment here their priority list length, if using the "priority list only" priority mode, or include their dump file otherwise. The number of linked games with campaigns to them would be enough, but that may be hard to determine in the other priority modes. d4cfcb5 has been pushed to increase the GQL rate limit a bit, which should help to mitigate the issue somewhat. I'd still recommend trimming down on the games you won't need though. |
It's def possible, as I'm near 40 games myself (currently at 37 and adding more every so often whenever I see a game I might be interested in playing or am playing) and rarely (like once in a blue moon type of situation so it's very very rare) ever miss a drop with the miner running 24/7. Anyways I've yet to run into this error myself even with games like |
|
Not using the priority list at all and have received the Unsure if GQL hash is still needed. But leaving my dev tools open for now to see if I can get something useful. Edit Hash for |
|
I've had it twice for rust in the last few hours, with only 2 games in the list. I sadly didn't think to record the errors but I will keep an eye out for them again. Just in case of the bug others have mentioned above, I have added lost ark to the ignore list. |
|
|
|
Same error ('claimDropRewards') happens for me every time miner claims a reward, works fine after I restart application until the next reward is claimed. |
|
I am constantly having this issue as well, here is the traceback I got: |
|
Has any of you checked if the drop is actually claimed in the inventory page? If not, what happens when you try to claim it yourself? Or does it display a message like "Expired" or smth like that? |
|
well since i would guess i need to move my answers to here |
|
I haven't actually experienced the issue in the past couple days. So no news to report here. Odd it went away. |
|
Hello, I've experienced this issue in the morning and now no longer experience it. I'm not a coder so I don't know what exactly is wrong but I have an idea of what could be the cause. This morning after experiencing the issue I decreased the amount of games listed on my priority list, which solved the problem. Later on in the day once some drops were completed I added back the previous games I had removed onto the list with no issues. Could it be possible that something in the program is being overloaded with the number of channels it is tracking and listing, thus crashing the game? I could be wrong, but I would assume if each campaign was limited to only listing up to 10 channels (currently some list 20+) and if offline channels were removed and then replaced, it could prevent the program from crashing. |
The limit is applied after the list of channel candidates is processed. The candidates are collected based on the selected games and campaigns present (no campaign, no channels collected for it's game). For campaigns that do not define an ACL, a list of like 20-30 live channels is collected. For campaigns with an ACL, the entire ACL is collected - and some campaigns define really long ACLs. Ravendawn campaigns alone define over 1000 channels, 5 times the amount the miner cares about and can support. With the current GQL rate limit of 10/1, checking the status of all those channels takes 100 seconds at best. If you add many more games to this, the reload time becomes longer and longer, which is okay assuming it wouldn't eventually crash, yet it still does sometimes. #554 (comment) has a list of games that define really long ACLs, having which as a mining candidate will cause the most trouble with the miner. The issue itself also explains what happens if the online status check is skipped entirely. I can see an optimization that would avoid double-checking the channels that were already tracked by the miner up to the reload point, but that'll only reduce the to-check list by ~200 channels. The miner was never designed nor expected to handle that many channels, and I don't really know what to do. All of those channels need to be processed to semi-guarantee correct functioning and proper fallback, when other channels decide to go offline. |
|
oh it works for me again buuut specially now claiming rust everytime its done with one it just gives this error: |
|
"PersistedQueryNotFound" implies the "DropCampaignDetails" GQL operation needs a new hash. I'll get on this in a few hours once I'm home. |
I would assume people order their priority list based on what they want most vs. least. Would it help if instead of searching all channels at once, it would only search the first x channels of the priority list and add more games lower in the priority list over time as the upper one's campaigns are complete? It wouldn't be necessary to keep track of the 5 games at the very bottom when the 5 games at the top are active and already take several hours to complete. In cases where all the channels of the upper campaigns are offline, you can then start checking lower campaigns until one that is online is found. |
|
You're not wrong, but you're also talking about something that would require a substantial rewrite of the miner's internals, something that I'd only consider doing for #220. Also, everything works just fine if you're not trying to cram in 40+ games into this thing. At this point, it makes more sense to me to put a straight up hard limit on how many games you can add to the miner, and that's it. |
As long as some of the campaigns are previously claimed the error doesn't appear (currently I have everything added with no problems because most of the things I actually want are already claimed). Instead of having a hard limit you could just give a warning to decrease the amount of games listed to users. (hopefully, that will also stop new users from coming on here). |
16:04:58: Fatal error encountered:
16:04:58:
16:04:58: Traceback (most recent call last):
16:04:58: File "main.py", line 155, in main
16:04:58: File "twitch.py", line 587, in run
16:04:58: File "twitch.py", line 747, in _run
16:04:58: File "twitch.py", line 1657, in bulk_check_online
16:04:58: File "asyncio\tasks.py", line 571, in _wait_for_one
16:04:58: File "twitch.py", line 1387, in gql_request
16:04:58: exceptions.GQLException: [{'message': 'service error', 'path': ['channel', 'viewerDropCampaigns']}]
16:04:58:
16:04:58: Exiting...
16:04:58:
16:04:58: Application Terminated.
16:04:58: Close the window to exit the application.
This error stops occurring when I exclude “Lost Ark” from the list.
The text was updated successfully, but these errors were encountered: