Errors that started after the release of versions 2.0.1, 2.0.2, 2.0.3, 2.0.4

[Ewcounless]

Describe the bug

As of November 22, 2025, having thoroughly tested all versions (2.0.1, 2.0.2, 2.0.3, 2.0.4), I can confidently say that we are dealing with new bugs/errors that, I believe, originate from version 2.0.1.

These aren't catastrophic errors that prevent the script from being used. But these are errors that greatly affect the work with the script.

Now I can't be sure that everything will work as expected without spending 30-60 minutes testing it at startup.

Now I can't be sure that when I go AFK, the script won't get an error that will stop it from working as intended, but at the same time it won't close itself.

Now I can't be sure that errors won't start appearing in large numbers that affect the hardware.

For example:
Now, instead of minimizing a script immediately after launching it, I leave it running for 30-60 minutes to ensure there are no critical issues at the start that require restarting the script.
Also, if I need to "loot" for 12 hours, the script can get a critical error, say, at the 4-5-6 hour mark of looting, after which the progress will not be counted, and if I do not notice this and do not restart it, I can not only lose 6-7-8 hours, I may not even be able to do what had a daily limit.

A critical error at startup may prevent the process from starting, and the script may remain active:

Traceback (most recent call last):
  File "C:\TWITCH_DROPS_MINER\run.py", line 72, in <module>
    twitch_miner.mine(
    ~~~~~~~~~~~~~~~~~^
        [
        ^
    ...<4 lines>...
        followers_order=FollowersOrder.ASC
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "C:\TWITCH_DROPS_MINER\TwitchChannelPointsMiner\TwitchChannelPointsMiner.py", line 211, in mine
    self.run(streamers=streamers, blacklist=blacklist, followers=followers)
    ~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\TWITCH_DROPS_MINER\TwitchChannelPointsMiner\TwitchChannelPointsMiner.py", line 299, in run
    self.twitch.check_streamer_online(streamer)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^
  File "C:\TWITCH_DROPS_MINER\TwitchChannelPointsMiner\classes\Twitch.py", line 188, in check_streamer_online
    self.update_stream(streamer)
    ~~~~~~~~~~~~~~~~~~^^^^^^^^^^
  File "C:\TWITCH_DROPS_MINER\TwitchChannelPointsMiner\classes\Twitch.py", line 100, in update_stream
    stream_info = self.get_stream_info(streamer)
  File "C:\TWITCH_DROPS_MINER\TwitchChannelPointsMiner\classes\Twitch.py", line 176, in get_stream_info
    if response["data"]["user"]["stream"] is None:
       ~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^
TypeError: 'NoneType' object is not subscriptable

Traceback (most recent call last):
  File "C:\TWITCH_DROPS_MINER\run.py", line 72, in <module>
    twitch_miner.mine(
    ~~~~~~~~~~~~~~~~~^
        [
        ^
    ...<4 lines>...
        followers_order=FollowersOrder.ASC
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "C:\TWITCH_DROPS_MINER — main\TwitchChannelPointsMiner\TwitchChannelPointsMiner.py", line 211, in mine
    self.run(streamers=streamers, blacklist=blacklist, followers=followers)
    ~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\TWITCH_DROPS_MINER — main\TwitchChannelPointsMiner\TwitchChannelPointsMiner.py", line 298, in run
    self.twitch.load_channel_points_context(streamer)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^
  File "C:\TWITCH_DROPS_MINER — main\TwitchChannelPointsMiner\classes\Twitch.py", line 674, in load_channel_points_context
    community_points = channel["self"]["communityPoints"]
                       ~~~~~~~^^^^^^^^
TypeError: 'NoneType' object is not subscriptable

Traceback (most recent call last):
  File "C:\TWITCH_DROPS_MINER\SCRIPT_NAME.py", line 72, in <module>
    twitch_miner.mine(
    ~~~~~~~~~~~~~~~~~^
        [
        ^
    ...<4 lines>...
        followers_order=FollowersOrder.ASC
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "C:\TWITCH_DROPS_MINER\TwitchChannelPointsMiner\TwitchChannelPointsMiner.py", line 211, in mine
    self.run(streamers=streamers, blacklist=blacklist, followers=followers)
    ~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\TWITCH_DROPS_MINER\TwitchChannelPointsMiner\TwitchChannelPointsMiner.py", line 299, in run
    self.twitch.check_streamer_online(streamer)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^
  File "C:\TWITCH_DROPS_MINER\TwitchChannelPointsMiner\classes\Twitch.py", line 188, in check_streamer_online
    self.update_stream(streamer)
    ~~~~~~~~~~~~~~~~~~^^^^^^^^^^
  File "C:\TWITCH_DROPS_MINER\TwitchChannelPointsMiner\classes\Twitch.py", line 104, in update_stream
    title=stream_info["broadcastSettings"]["title"],
          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^
TypeError: 'NoneType' object is not subscriptable

===========================================================
lines 72 - 79 in SCRIPT_NAME.py :
===========================================================

twitch_miner.mine(
    [
        Streamer("STREAMER_FOR_LOOTING_1", settings=StreamerSettings(make_predictions=False  , follow_raid=False , claim_drops=True  , watch_streak=False , community_goals=False , bet=BetSettings(strategy=Strategy.SMART      , percentage=5 , stealth_mode=True,  percentage_gap=20 , max_points=50000   , filter_condition=FilterCondition(by=OutcomeKeys.TOTAL_USERS,      where=Condition.LTE, value=800 ) ) )),
        Streamer("STREAMER_FOR_LOOTING_2", settings=StreamerSettings(make_predictions=False  , follow_raid=False , claim_drops=True  , watch_streak=False , community_goals=False , bet=BetSettings(strategy=Strategy.SMART      , percentage=5 , stealth_mode=True,  percentage_gap=20 , max_points=50000   , filter_condition=FilterCondition(by=OutcomeKeys.TOTAL_USERS,      where=Condition.LTE, value=800 ) ) ))
    ],
    followers=False,
    followers_order=FollowersOrder.ASC
)

Exception in thread Thread-10 (run):
Traceback (most recent call last):
  File "C:\Users\PC\AppData\Local\Programs\Python\Python313\Lib\threading.py", line 1041, in _bootstrap_inner
    self.run()
    ~~~~~~~~^^
  File "C:\Users\PC\AppData\Local\Programs\Python\Python313\Lib\threading.py", line 992, in run
    self._target(*self._args, **self._kwargs)
    ~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\TWITCH_DROPS_MINER\TwitchChannelPointsMiner\classes\WebSocketsPool.py", line 106, in run
    ws.ping()  # We need ping for keep the connection alive
    ~~~~~~~^^
  File "C:\TWITCH_DROPS_MINER\TwitchChannelPointsMiner\classes\TwitchWebSocket.py", line 50, in ping
    self.send({"type": "PING"})
    ~~~~~~~~~^^^^^^^^^^^^^^^^^^
  File "C:\TWITCH_DROPS_MINER\TwitchChannelPointsMiner\classes\TwitchWebSocket.py", line 57, in send
    super().send(request_str)
    ~~~~~~~~~~~~^^^^^^^^^^^^^
  File "C:\Users\PC\AppData\Local\Programs\Python\Python313\Lib\site-packages\websocket\_app.py", line 290, in send    if not self.sock or self.sock.send(data, opcode) == 0:
                        ~~~~~~~~~~~~~~^^^^^^^^^^^^^^
  File "C:\Users\PC\AppData\Local\Programs\Python\Python313\Lib\site-packages\websocket\_core.py", line 297, in send
    return self.send_frame(frame)
           ~~~~~~~~~~~~~~~^^^^^^^
  File "C:\Users\PC\AppData\Local\Programs\Python\Python313\Lib\site-packages\websocket\_core.py", line 337, in send_frame
    l = self._send(data)
  File "C:\Users\PC\AppData\Local\Programs\Python\Python313\Lib\site-packages\websocket\_core.py", line 559, in _send
    return send(self.sock, data)
  File "C:\Users\PC\AppData\Local\Programs\Python\Python313\Lib\site-packages\websocket\_socket.py", line 179, in send
    return _send()
  File "C:\Users\PC\AppData\Local\Programs\Python\Python313\Lib\site-packages\websocket\_socket.py", line 156, in _send
    return sock.send(data)
           ~~~~~~~~~^^^^^^
  File "C:\Users\PC\AppData\Local\Programs\Python\Python313\Lib\ssl.py", line 1232, in send
    return self._sslobj.write(data)
           ~~~~~~~~~~~~~~~~~~^^^^^^

Exception raised in send minute watched
Traceback (most recent call last):
  File "C:\TWITCH_DROPS_MINER\TwitchChannelPointsMiner\classes\Twitch.py", line 577, in send_minute_watched_events
    response = requests.post(
        streamers[index].stream.spade_url,
    ...<3 lines>...
        timeout=20,
    )
  File "C:\Users\PC\AppData\Local\Programs\Python\Python313\Lib\site-packages\requests\api.py", line 115, in post
    return request("post", url, data=data, json=json, **kwargs)
  File "C:\Users\PC\AppData\Local\Programs\Python\Python313\Lib\site-packages\requests\api.py", line 59, in request
    return session.request(method=method, url=url, **kwargs)
           ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\PC\AppData\Local\Programs\Python\Python313\Lib\site-packages\requests\sessions.py", line 575, in request
    prep = self.prepare_request(req)
  File "C:\Users\PC\AppData\Local\Programs\Python\Python313\Lib\site-packages\requests\sessions.py", line 484, in prepare_request
    p.prepare(
    ~~~~~~~~~^
        method=request.method.upper(),
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<10 lines>...
        hooks=merge_hooks(request.hooks, self.hooks),
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "C:\Users\PC\AppData\Local\Programs\Python\Python313\Lib\site-packages\requests\models.py", line 367, in prepare
    self.prepare_url(url, params)
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "C:\Users\PC\AppData\Local\Programs\Python\Python313\Lib\site-packages\requests\models.py", line 438, in prepare_url
    raise MissingSchema(
    ...<2 lines>...
    )
requests.exceptions.MissingSchema: Invalid URL 'None': No scheme supplied. Perhaps you meant https://None?

Exception raised in send minute watched
Traceback (most recent call last):
  File "C:\TWITCH_DROPS_MINER\TwitchChannelPointsMiner\classes\Twitch.py", line 577, in send_minute_watched_events
    response = requests.post(
        streamers[index].stream.spade_url,
    ...<3 lines>...
        timeout=20,
    )
  File "C:\Users\PC\AppData\Local\Programs\Python\Python313\Lib\site-packages\requests\api.py", line 115, in post
    return request("post", url, data=data, json=json, **kwargs)
  File "C:\Users\PC\AppData\Local\Programs\Python\Python313\Lib\site-packages\requests\api.py", line 59, in request
    return session.request(method=method, url=url, **kwargs)
           ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\PC\AppData\Local\Programs\Python\Python313\Lib\site-packages\requests\sessions.py", line 575, in request
    prep = self.prepare_request(req)
  File "C:\Users\PC\AppData\Local\Programs\Python\Python313\Lib\site-packages\requests\sessions.py", line 484, in prepare_request
    p.prepare(
    ~~~~~~~~~^
        method=request.method.upper(),
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<10 lines>...
        hooks=merge_hooks(request.hooks, self.hooks),
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "C:\Users\PC\AppData\Local\Programs\Python\Python313\Lib\site-packages\requests\models.py", line 367, in prepare
    self.prepare_url(url, params)
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "C:\Users\PC\AppData\Local\Programs\Python\Python313\Lib\site-packages\requests\models.py", line 438, in prepare_url
    raise MissingSchema(
    ...<2 lines>...
    )
requests.exceptions.MissingSchema: Invalid URL 'None': No scheme supplied. Perhaps you meant https://None?

Also, one of the above errors may appear after any amount of time of operation and the looting process will stop without closing the script.

Non-critical errors that complicate the script's operation by placing additional load on the hardware, but looting does not stop:

Error with GQLOperations (PlaybackAccessToken): HTTPSConnectionPool(host='gql.twitch.tv', port=443): Max retries exceeded with url: /gql (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x000002A7DD789090>: Failed to establish a new connection: [WinError 10048] Обычно разрешается только одно использование адреса сокета (протокол/сетевой адрес/порт)'))

Error while trying to send minute watched: HTTPSConnectionPool(host='9c6ee9e29d42.j.cloudfront.hls.ttvnw.net', port=443): Max retries exceeded with url: /v1/segment/CscCrjk3uMv2QNkh10YgFuuUmKT1a9lVkNnucJe_niC2ig7szyW-lzeBxQ0FpoZ7ohpiPTW22vJ9FDtjmBXO-HTDYoc5eSqMWHZW8NQVf0p8kNN6P8IDd9kbfcDCTl7THX3O-unilHTWfC1AKEIpC5Q9TBjEJO8xzLAWo-73dxaO82VNUrnuI_8TWG_txAZPoG1lqiUBcWl1Nt1A33lMVIbx3_5cubos_yaQtRTnp1zxoWMxcTY7uvLT46YhxeQVqkWbDMCf7iZjvxB0jPQvT7faqW-g9f039BiXihH3ykpuqF1UpVAdVKJc6s-trGr3lZjir7D3dZky8OyuTRddxWf9EDGyt8Io5jylrH-yUxKXjt4WCP3NaI34hJtVu37zgDnuaVxRLWHttbxYnUvTdKzwVp6OALK7PcAG2QQm7ixeNPBqmTqQ22ezGgyqBOYlYD3zazz7hd0gASoJZXUtd2VzdC0yMN8N.mp4?dna=CnvTTpL6BE1Tj2dIQDGZ3JFyz7TnXwrpR_NA8WWcnCL3nAd5fXfs6vTUGsowwRKe65HsEtsGLdhv1eHB6_K9XipNg3S4sRDeg1bGR2ujJf_ZgQHdd8VtlEr2pzCyIUMIC5QQlP_y8EEoOUUuIDRFzEbDLzm2qhDl9wHzmRwaDDA462YexmyVbFjq2SABKglldS13ZXN0LTIw3w0 (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x000002A7DD789950>: Failed to establish a new connection: [WinError 10048] Обычно разрешается только одно использование адреса сокета (протокол/сетевой адрес/порт)'))

Error with update_client_version: HTTPSConnectionPool(host='www.twitch.tv', port=443): Max retries exceeded with url: / (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x000001A69A2AF9D0>: Failed to establish a new connection: [WinError 10048] Обычно разрешается только одно использование адреса сокета (протокол/сетевой адрес/порт)'))

19/11 13:45:58 - [TWITCH_USERNAME] #0 - WebSocket closed
19/11 13:45:58 - [TWITCH_USERNAME] #0 - Reconnecting to Twitch PubSub server in ~60 seconds
19/11 13:46:29 - [TWITCH_USERNAME] #0 - WebSocket closed
19/11 13:46:29 - [TWITCH_USERNAME] #0 - Reconnecting to Twitch PubSub server in ~60 seconds
19/11 13:46:59 - [TWITCH_USERNAME] #0 - WebSocket closed
19/11 13:46:59 - [TWITCH_USERNAME] #0 - Reconnecting to Twitch PubSub server in ~60 seconds
19/11 13:47:30 - [TWITCH_USERNAME] #0 - WebSocket closed
19/11 13:47:30 - [TWITCH_USERNAME] #0 - Reconnecting to Twitch PubSub server in ~60 seconds
19/11 13:48:00 - [TWITCH_USERNAME] #0 - WebSocket closed
19/11 13:48:00 - [TWITCH_USERNAME] #0 - Reconnecting to Twitch PubSub server in ~60 seconds
19/11 13:48:31 - [TWITCH_USERNAME] #0 - WebSocket closed
19/11 13:48:31 - [TWITCH_USERNAME] #0 - Reconnecting to Twitch PubSub server in ~60 seconds
19/11 13:49:01 - [TWITCH_USERNAME] #0 - WebSocket closed
19/11 13:49:01 - [TWITCH_USERNAME] #0 - Reconnecting to Twitch PubSub server in ~60 seconds
19/11 13:49:32 - [TWITCH_USERNAME] #0 - WebSocket closed
19/11 13:49:32 - [TWITCH_USERNAME] #0 - Reconnecting to Twitch PubSub server in ~60 seconds
19/11 13:50:02 - [TWITCH_USERNAME] #0 - WebSocket closed
19/11 13:50:02 - [TWITCH_USERNAME] #0 - Reconnecting to Twitch PubSub server in ~60 seconds
19/11 13:50:33 - [TWITCH_USERNAME] #0 - WebSocket closed
19/11 13:50:33 - [TWITCH_USERNAME] #0 - Reconnecting to Twitch PubSub server in ~60 seconds
19/11 13:51:03 - [TWITCH_USERNAME] #0 - WebSocket closed
19/11 13:51:03 - [TWITCH_USERNAME] #0 - Reconnecting to Twitch PubSub server in ~60 seconds
19/11 13:51:33 - [TWITCH_USERNAME] #0 - No internet connection available! Retry after 2m
19/11 13:53:34 - [TWITCH_USERNAME] #0 - WebSocket closed
19/11 13:53:34 - [TWITCH_USERNAME] #0 - Reconnecting to Twitch PubSub server in ~60 seconds
19/11 13:54:04 - [TWITCH_USERNAME] #0 - No internet connection available! Retry after 3m
19/11 13:57:04 - [TWITCH_USERNAME] #0 - WebSocket closed
19/11 13:57:04 - [TWITCH_USERNAME] #0 - Reconnecting to Twitch PubSub server in ~60 seconds
19/11 13:57:35 - [TWITCH_USERNAME] #0 - WebSocket closed
19/11 13:57:35 - [TWITCH_USERNAME] #0 - Reconnecting to Twitch PubSub server in ~60 seconds
19/11 13:58:05 - [TWITCH_USERNAME] #0 - WebSocket closed
19/11 13:58:05 - [TWITCH_USERNAME] #0 - Reconnecting to Twitch PubSub server in ~60 seconds
19/11 13:58:36 - [TWITCH_USERNAME] #0 - WebSocket closed
19/11 13:58:36 - [TWITCH_USERNAME] #0 - Reconnecting to Twitch PubSub server in ~60 seconds
19/11 13:59:06 - [TWITCH_USERNAME] #0 - WebSocket closed
19/11 13:59:06 - [TWITCH_USERNAME] #0 - Reconnecting to Twitch PubSub server in ~60 seconds
19/11 13:59:37 - [TWITCH_USERNAME] #0 - WebSocket closed
19/11 13:59:37 - [TWITCH_USERNAME] #0 - Reconnecting to Twitch PubSub server in ~60 seconds
19/11 14:00:07 - [TWITCH_USERNAME] #0 - WebSocket closed
19/11 14:00:07 - [TWITCH_USERNAME] #0 - Reconnecting to Twitch PubSub server in ~60 seconds

19/11 13:52:14 - [TWITCH_USERNAME] Error with GQLOperations (DropsHighlightService_AvailableDrops): HTTPSConnectionPool(host='gql.twitch.tv', port=443): Max retries exceeded with url: /gql (Caused by ConnectTimeoutError(<urllib3.connection.HTTPSConnection object at 0x000001D378009310>, 'Connection to gql.twitch.tv timed out. (connect timeout=None)'))
19/11 13:52:14 - [TWITCH_USERNAME] #0 - WebSocket error: [WinError 10053] Программа на вашем хост-компьютере разорвала установленное подключение
19/11 13:52:14 - [TWITCH_USERNAME] [WinError 10053] Программа на вашем хост-компьютере разорвала установленное подключение - goodbye
19/11 13:52:14 - [TWITCH_USERNAME] #0 - WebSocket closed
19/11 13:52:14 - [TWITCH_USERNAME] #0 - Reconnecting to Twitch PubSub server in ~60 seconds

My run.py: https://gist.github.com/Ewcounless/40ebccee0edb018c10464d95e4e0056a#file-gistfile1-txt

My computer hasn't been changed in years. The software hasn't been changed in years.
No antivirus. Firewall disabled.
Internet: 1 Gigabit. Dedicated line. Real static IP address. I don't use a proxy or VPN.
There have been absolutely no changes since the release of script versions 2.0.1-2.0.4.
Before patch 2.0.1, everything worked perfectly, without any issues. I have always been confident in the correct operation of the script and have learned to work with it quite well under any conditions.
I also worked with the script both before and after patches 2.0.1-2.0.4 were released on a different computer with different hardware and a different internet provider. Both computers were configured identically.
Everything was fine until the moment when a fix was needed on November 10, 2025.

Steps to reproduce

Normal script launch, but more often in multi-mode.
But errors were also noticed in single mode.

1. Launch
2. Wait

Expected behavior

It's critically important to fix any catastrophic errors that affect the script's operation. This is the most important thing.

It's advisable to fix any errors that don't affect the script's operation.

Operating system

Windows 10 Version 22H2 (OS Build 19045.6456)

Python version

3.13.0

Miner version

2.0.1-2.0.4

Other relevant software versions

No response

Logs

DEBUG log is disabled
update:

I specifically set aside 30 minutes of time with the DEBUG LOG enabled.
Unfortunately, I didn't manage to capture the catastrophic error, but I did catch a critical error, but the looting didn't stop.
The exact same error occurs when looting stops, only then it starts spamming constantly every n seconds.
Unfortunately, in this log, looting even started, and then this error popped up.
When it appears in a catastrophic case, looting doesn't even begin.

DEBUG LOG: https://gist.github.com/Ewcounless/f8f097fe679bcc023f42979edfa13ed8#file-gistfile1-txt
SCRIPT LOG: https://gist.github.com/Ewcounless/0401f29a44d61bbd7bb342ada7e8ee27#file-gistfile1-txt

Additional context

No response

[Xalvior]

I’m currently running into exactly the same errors and issues. Now, instead of launching it and forgetting about it, I have to monitor the consoles’ activity for an extended period via "Task View" (Win+Tab). I first have to start the script in multi-instance mode and keep the consoles unminimized so that each one remains visible in Task View in case it crashes. Then I have to manually restart each affected console, because in addition to the non-critical errors which don’t prevent normal operation (they just create a slightly heavier load on the hardware than usual) there can also be critical ones that get stuck in a loop and spam errors every second, with no ability to recover on their own. The only way to fix it is to restart the specific console instance that failed.

Another nuance is that in "Task View" you can’t always immediately spot which console has the critical error from the preview, so you either have to check each one in turn or randomly try clicking through them until you find the one that needs help to resume normal operation.

[mpforce1]

DEBUG LOG: https://gist.github.com/Ewcounless/f8f097fe679bcc023f42979edfa13ed8#file-gistfile1-txt SCRIPT LOG: https://gist.github.com/Ewcounless/0401f29a44d61bbd7bb342ada7e8ee27#file-gistfile1-txt

@Ewcounless Thanks for getting the DEBUG logs! I can clearly see the error you're seeing is in handling the response to VideoPlayerStreamInfoOverlayChannel:

{
    "errors": [{
            "message": "service timeout",
            "path": ["user"]
        }
    ],
    "data": {
        "user": null
    },
    "extensions": {
        "durationMilliseconds": ...,
        "operationName": "VideoPlayerStreamInfoOverlayChannel",
        "requestID": "..."
    }
}

I mention this error in #748 (comment), seems like Twitch is having backend issues that cause occasional internal timeouts. The service timeout error here suggests (although I can't say for certain) that Twitch's server's GQL layer looks at the query and attempts to load each part separately, in this case their user service gets invoked but doesn't return quickly enough. I can't say why this is happening more frequently now, perhaps they happened to change something around the 2.0.1 release, or maybe the release just changed something that surfaced errors that were already happening. Hard to say.

For now, you've seen PR #753, this has some changes that could potentially help mitigate this issue. I'm currently working on a more comprehensive fix but it'll be a while. Have a go with that branch and see if it helps.

[Ewcounless]

DEBUG LOG: https://gist.github.com/Ewcounless/f8f097fe679bcc023f42979edfa13ed8#file-gistfile1-txt SCRIPT LOG: https://gist.github.com/Ewcounless/0401f29a44d61bbd7bb342ada7e8ee27#file-gistfile1-txt

@Ewcounless Thanks for getting the DEBUG logs! I can clearly see the error you're seeing is in handling the response to VideoPlayerStreamInfoOverlayChannel:

{
"errors": [{
"message": "service timeout",
"path": ["user"]
}
],
"data": {
"user": null
},
"extensions": {
"durationMilliseconds": ...,
"operationName": "VideoPlayerStreamInfoOverlayChannel",
"requestID": "..."
}
}
I mention this error in #748 (comment), seems like Twitch is having backend issues that cause occasional internal timeouts. The service timeout error here suggests (although I can't say for certain) that Twitch's server's GQL layer looks at the query and attempts to load each part separately, in this case their user service gets invoked but doesn't return quickly enough. I can't say why this is happening more frequently now, perhaps they happened to change something around the 2.0.1 release, or maybe the release just changed something that surfaced errors that were already happening. Hard to say.

For now, you've seen PR #753, this has some changes that could potentially help mitigate this issue. I'm currently working on a more comprehensive fix but it'll be a while. Have a go with that branch and see if it helps.

In the link in another thread, you wrote: "I'm currently working on a fix for the miner's GQL integration layer that will automatically handle this sort of error."

"That will automatically handle this sort of error" - I didn't fully understand that phrase. What do you want to do with automatic handling? To eliminate the problem entirely, or to hide its appearance in the console? What is the purpose of this handling? So the error will still appear, but after it appears, the script should automatically return to proper operation (resume the viewing/looting process)?

Also, I didn't find in that thread any changes you proposed as a temporary solution or an attempt to solve this problem.
update:
Apparently, I was able to find the fixes they were talking about: 88e3e40
But... I can imagine that the changes in twitch.py ​​might help, but I don't understand how everything else, particularly the changes in streamer.py, relates to the problem I've identified.

"I'm currently working on a more comprehensive fix, but it'll be a while." - when can we expect it (presumably)? And what result do you hope to achieve in this case?

P.S.: I'll try to find time tonight to create a new debug log.

[mpforce1]

"That will automatically handle this sort of error" - I didn't fully understand that phrase. What do you want to do with automatic handling? To eliminate the problem entirely, or to hide its appearance in the console? What is the purpose of this handling? So the error will still appear, but after it appears, the script should automatically return to proper operation (resume the viewing/looting process)?

As in, if it's a service timeout error, we can have the miner automatically retry the request without warning the user since timeouts can just be a temporary issue. I'm thinking we do 3 (or maybe a configurable amount) of retries and then warn the user.

Also, I didn't find in that thread any changes you proposed as a temporary solution or an attempt to solve this problem. update: Apparently, I was able to find the fixes they were talking about: 88e3e40 But... I can imagine that the changes in twitch.py ​​might help, but I don't understand how everything else, particularly the changes in streamer.py, relates to the problem I've identified.

Yeah, that PR has several changes in it, it's not all relevant to your issue. In particular, there's now some error handling around some GQL requests that surfaces a better error message to the user. So it won't fix your issue but it might make it easier to debug in the future.

"I'm currently working on a more comprehensive fix, but it'll be a while." - when can we expect it (presumably)? And what result do you hope to achieve in this case?

Currently working through it, no hard promises but I'll try to have it done in the next few days. I'm trying to separate out the GQL request/response specific code from the functionality of the Twitch class, using the single responsibility principle it doesn't really make sense for that to all be handled by the same class. I've currently got a Parser type that just checks the GQL response to see if there are any issues. Then, if there are, you get a nicely formatted Exception that we can use to identify the issue.

The API can change at a moment's notice, Twitch has no obligation to us, so this sort of thing just happens and I thought it'd be really nice to get some more useful error logs.

P.S.: I'll try to find time tonight to create a new debug log.

Thanks, I appreciate it.

[Ewcounless]

"That will automatically handle this sort of error" - I didn't fully understand that phrase. What do you want to do with automatic handling? To eliminate the problem entirely, or to hide its appearance in the console? What is the purpose of this handling? So the error will still appear, but after it appears, the script should automatically return to proper operation (resume the viewing/looting process)?

As in, if it's a service timeout error, we can have the miner automatically retry the request without warning the user since timeouts can just be a temporary issue. I'm thinking we do 3 (or maybe a configurable amount) of retries and then warn the user.

Also, I didn't find in that thread any changes you proposed as a temporary solution or an attempt to solve this problem. update: Apparently, I was able to find the fixes they were talking about: 88e3e40 But... I can imagine that the changes in twitch.py ​​might help, but I don't understand how everything else, particularly the changes in streamer.py, relates to the problem I've identified.

Yeah, that PR has several changes in it, it's not all relevant to your issue. In particular, there's now some error handling around some GQL requests that surfaces a better error message to the user. So it won't fix your issue but it might make it easier to debug in the future.

"I'm currently working on a more comprehensive fix, but it'll be a while." - when can we expect it (presumably)? And what result do you hope to achieve in this case?

Currently working through it, no hard promises but I'll try to have it done in the next few days. I'm trying to separate out the GQL request/response specific code from the functionality of the Twitch class, using the single responsibility principle it doesn't really make sense for that to all be handled by the same class. I've currently got a Parser type that just checks the GQL response to see if there are any issues. Then, if there are, you get a nicely formatted Exception that we can use to identify the issue.

The API can change at a moment's notice, Twitch has no obligation to us, so this sort of thing just happens and I thought it'd be really nice to get some more useful error logs.

P.S.: I'll try to find time tonight to create a new debug log.

Thanks, I appreciate it.

1. So, that PR was just a debug log improvement, not an attempt to solve the problem itself?
2. Next time when I create a debug log, should I include these changes (from that PR)?
3. Will the upcoming fix solve the problem, or will it simply try to retry the action several times, and if the response is negative, the script will still stop looting?
4. Will the upcoming fix solve errors like "Error while trying to send minute watched:", "Error with update_client_version:", "WebSocket closed #0 - Reconnecting to Twitch PubSub server in ~60 seconds", and "WinError 10053"?
5. Unfortunately, I won't be able to create a debug log today, but I'll try tomorrow.

P.S.: ty for your work and improving the script.

[mpforce1]

1. So, that PR was just a debug log improvement, not an attempt to solve the problem itself?

2. Next time when I create a debug log, should I include these changes (from that PR)?

3. Will the upcoming fix solve the problem, or will it simply try to retry the action several times, and if the response is negative, the script will still stop looting?

4. Will the upcoming fix solve errors like "Error while trying to send minute watched:", "Error with update_client_version:", "WebSocket closed #0 - Reconnecting to Twitch PubSub server in ~60 seconds", and "WinError 10053"?

5. Unfortunately, I won't be able to create a debug log today, but I'll try tomorrow.

P.S.: ty for your work and improving the script.

1. The problem is ultimately on Twitch's end, there's nothing we can do to solve the root cause. All we can do is attempt to retry timed out requests and reduce logging.
2. Yeah, I'd like to see if you get the same number of logs and if they're more useful for you (and us debuggers).
3. Again, we cannot solve the root cause, it's not ultimately a problem with the miner.
4. You'll get more useful logs with better context for those first 2, the WebSocket one is a separate thing that happens when Twitch disconnects the WebSocket connection (or network stability issues). That seems to be happening more often now, but it's once again Twitch doing it. The best thing we could do is remove that log, and in the upcoming Hermes WebSocket integration I have attempted to reduce that particular log. But that feature's not currently merged into the main branch.
5. No worries, whenever you can 😄

[Ewcounless]

1. So, that PR was just a debug log improvement, not an attempt to solve the problem itself?

2. Next time when I create a debug log, should I include these changes (from that PR)?

3. Will the upcoming fix solve the problem, or will it simply try to retry the action several times, and if the response is negative, the script will still stop looting?

4. Will the upcoming fix solve errors like "Error while trying to send minute watched:", "Error with update_client_version:", "WebSocket closed #0 - Reconnecting to Twitch PubSub server in ~60 seconds", and "WinError 10053"?

5. Unfortunately, I won't be able to create a debug log today, but I'll try tomorrow.

P.S.: ty for your work and improving the script.

1. The problem is ultimately on Twitch's end, there's nothing we can do to solve the root cause. All we can do is attempt to retry timed out requests and reduce logging.
2. Yeah, I'd like to see if you get the same number of logs and if they're more useful for you (and us debuggers).
3. Again, we cannot solve the root cause, it's not ultimately a problem with the miner.
4. You'll get more useful logs with better context for those first 2, the WebSocket one is a separate thing that happens when Twitch disconnects the WebSocket connection (or network stability issues). That seems to be happening more often now, but it's once again Twitch doing it. The best thing we could do is remove that log, and in the upcoming Hermes WebSocket integration I have attempted to reduce that particular log. But that feature's not currently merged into the main branch.
5. No worries, whenever you can 😄

But in the old version of the script before 2.0.1 there were no such catastrophic errors and problems. 😟

[Ewcounless]

mpforce1
I didn't have time to make the changes to 88e3e40 for the logs.

But I encountered a catastrophic error where looting didn't even start. The same error I called "purple."

There's a debug log, but no regular log. I was hasty and accidentally closed the script :)

Debug log: https://gist.github.com/Ewcounless/8e4c4fd9a6955053c1feab838de441ed#file-gistfile1-txt

Is that enough now? Are your thoughts confirmed?

[0x8fv]

I’ve been digging into these errors and I’m pretty sure the root cause is how the current Python implementation assumes certain Twitch responses are always present, instead of defensively handling the cases where Twitch returns null / missing data.

All of the stack traces here fall into the same pattern:
TypeError: 'NoneType' object is not subscriptable in Twitch.py happens when fields like response["data"]["user"]["stream"] or channel["self"]["communityPoints"] are None, but the code still tries to index into them.

requests.exceptions.MissingSchema: Invalid URL 'None' in send_minute_watched_events happens when stream.spade_url is None and requests.post is called with that value as the URL.

In my Go recode of the miner I’ve fixed exactly these failure modes by treating “missing Twitch data” as a first‑class, expected condition instead of an exception.

For stream info: if data.user.stream is missing, the Go version returns a dedicated “streamer offline” error and marks the streamer as offline; if data.user is missing, it returns a clear error instead of indexing into None.
For channel points: if data.community.channel is missing, it returns a clear error and effectively skips that streamer;
if communityPoints fields are missing or malformed, it safely falls back to 0 points instead of crashing.
For spade_url: the code first resolves the URL from the Twitch page;
if it can’t be found, it returns an error and never calls the “minute watched” endpoint with a None/empty URL.
The main loop treats all of these as recoverable errors (offline, temporary network issues, missing data), logs them, and continues mining instead of stopping silently while the process stays open.
You can see the recoded implementation here, which runs stably under exactly the same Twitch behavior that currently breaks the Python version: https://github.com/0x8fv/Twitch-Channel-Points-Miner

In short: the Python errors are not really “new Twitch behavior” problems, but missing None / error handling around Twitch’s GQL and web responses. The Go port adds those guards everywhere, and as a result it doesn’t hit the catastrophic crashes described in this issue.

[Ewcounless]

I’ve been digging into these errors and I’m pretty sure the root cause is how the current Python implementation assumes certain Twitch responses are always present, instead of defensively handling the cases where Twitch returns null / missing data.

All of the stack traces here fall into the same pattern: TypeError: 'NoneType' object is not subscriptable in Twitch.py happens when fields like response["data"]["user"]["stream"] or channel["self"]["communityPoints"] are None, but the code still tries to index into them.

requests.exceptions.MissingSchema: Invalid URL 'None' in send_minute_watched_events happens when stream.spade_url is None and requests.post is called with that value as the URL.

In my Go recode of the miner I’ve fixed exactly these failure modes by treating “missing Twitch data” as a first‑class, expected condition instead of an exception.

For stream info: if data.user.stream is missing, the Go version returns a dedicated “streamer offline” error and marks the streamer as offline; if data.user is missing, it returns a clear error instead of indexing into None. For channel points: if data.community.channel is missing, it returns a clear error and effectively skips that streamer; if communityPoints fields are missing or malformed, it safely falls back to 0 points instead of crashing. For spade_url: the code first resolves the URL from the Twitch page; if it can’t be found, it returns an error and never calls the “minute watched” endpoint with a None/empty URL. The main loop treats all of these as recoverable errors (offline, temporary network issues, missing data), logs them, and continues mining instead of stopping silently while the process stays open. You can see the recoded implementation here, which runs stably under exactly the same Twitch behavior that currently breaks the Python version: https://github.com/0x8fv/Twitch-Channel-Points-Miner

In short: the Python errors are not really “new Twitch behavior” problems, but missing None / error handling around Twitch’s GQL and web responses. The Go port adds those guards everywhere, and as a result it doesn’t hit the catastrophic crashes described in this issue.

It sounds great and beautiful, but:

1. I have no idea what "Go" is.
2. Is "Go" a programming language? And you used it to write a complete clone of what we have here in Python?
3. Do you have multi-accounting capabilities?
4. How much more difficult is using your software than this one?
5. Is it possible to migrate existing cookies/script executables to run in Go?

After so many years of working on the Python version, if porting isn't possible, it will be extremely problematic to use.

If you had the advantage of a fully-fledged multi-accounting version, you could try, but without migrating existing accounts, it's an incredible waste of time and effort.

[0x8fv]

I’ve been digging into these errors and I’m pretty sure the root cause is how the current Python implementation assumes certain Twitch responses are always present, instead of defensively handling the cases where Twitch returns null / missing data.
All of the stack traces here fall into the same pattern: TypeError: 'NoneType' object is not subscriptable in Twitch.py happens when fields like response["data"]["user"]["stream"] or channel["self"]["communityPoints"] are None, but the code still tries to index into them.
requests.exceptions.MissingSchema: Invalid URL 'None' in send_minute_watched_events happens when stream.spade_url is None and requests.post is called with that value as the URL.
In my Go recode of the miner I’ve fixed exactly these failure modes by treating “missing Twitch data” as a first‑class, expected condition instead of an exception.
For stream info: if data.user.stream is missing, the Go version returns a dedicated “streamer offline” error and marks the streamer as offline; if data.user is missing, it returns a clear error instead of indexing into None. For channel points: if data.community.channel is missing, it returns a clear error and effectively skips that streamer; if communityPoints fields are missing or malformed, it safely falls back to 0 points instead of crashing. For spade_url: the code first resolves the URL from the Twitch page; if it can’t be found, it returns an error and never calls the “minute watched” endpoint with a None/empty URL. The main loop treats all of these as recoverable errors (offline, temporary network issues, missing data), logs them, and continues mining instead of stopping silently while the process stays open. You can see the recoded implementation here, which runs stably under exactly the same Twitch behavior that currently breaks the Python version: https://github.com/0x8fv/Twitch-Channel-Points-Miner
In short: the Python errors are not really “new Twitch behavior” problems, but missing None / error handling around Twitch’s GQL and web responses. The Go port adds those guards everywhere, and as a result it doesn’t hit the catastrophic crashes described in this issue.

It sounds great and beautiful, but:

1. I have no idea what "Go" is.
2. Is "Go" a programming language? And you used it to write a complete clone of what we have here in Python?
3. Do you have multi-accounting capabilities?
4. How much more difficult is using your software than this one?
5. Is it possible to migrate existing cookies/script executables to run in Go?

After so many years of working on the Python version, if porting isn't possible, it will be extremely problematic to use.

If you had the advantage of a fully-fledged multi-accounting version, you could try, but without migrating existing accounts, it's an incredible waste of time and effort.

Yes, Go is a programming language. This repo is a Go rewrite of the Python miner with very similar behavior (auto‑claims bonuses, drops, predictions, raids, etc.).

Multi‑account works the same way as the Python version: each account has its own cookie file in the cookies folder, and you switch accounts simply by changing the username in config.json. There’s no automatic migration of Python cookies or .exe builds. Each account needs one device login in the Go version to create its cookie, but after that you can swap between them just by changing username in config.json.

Usage is very similar: edit config.json and run it. You can either just run the provided executable (no Go installed, no Python, no virtualenv), or, if you prefer, install Go and run/build it yourself (go run . / go build).

Based on your run.py settings this should roughly translate to this config.json in the Go version:

{
  "username": "YOUR_TWITCH_USERNAME",
  "auto_update": true,
  "debug": false,
  "smart_logging": true,
  "disable_ssl_cert_verification": false,
  "show_seconds": false,
  "claim_drops_startup": true,
  "claim_drops": true,
  "betting(make_predictions)": false,
  "follow_raid": false,
  "community_goals": false,
  "emojis": true,
  "save_logs": false,
  "show_username_in_console": false,
  "show_claimed_bonus_msg": false,
  "streamers": [
    "STREAMER_FOR_LOOTING_1",
    "STREAMER_FOR_LOOTING_2"
  ],
  "watch_priority": [
    "STREAK",
    "DROPS",
    "ORDER"
  ],
  "password": "your-twitch-password (Optional)",
  "bet": {
    "strategy": "SMART",
    "percentage": 5,
    "percentage_gap": 20,
    "max_points": 50000,
    "stealth_mode": true,
    "delay_mode": null,
    "delay": null,
    "minimum_points": null
  }
}

If you have any other questions about my go script how ever please create a Threat on my repository...

[mpforce1]

But I encountered a catastrophic error where looting didn't even start. The same error I called "purple."

@Ewcounless

The "purple" errors are actually just how the console formats parts of python stack traces. A stack trace being a sort of history of the code being run to reach the error. The stack trace can show up for any type of error, not just these ones. So, the fact that the errors are "purple" doesn't mean they're related.

There's a debug log, but no regular log. I was hasty and accidentally closed the script :)

Debug log: https://gist.github.com/Ewcounless/8e4c4fd9a6955053c1feab838de441ed#file-gistfile1-txt

Is that enough now? Are your thoughts confirmed?

Oh thanks! I can see in there that this is indeed a service timeout issue. You have 2 VideoPlayerStreamInfoOverlayChannel requests in there and one returns normally, but the other returns a response with and errors field containing a service timeout. I can also see that earlier requests for both, getting their user ids, users succeed. This confirms to me that the issue is Twitch side and we just need better handling for GQL responses.

[dragoslys-source]

I’ve been digging into these errors and I’m pretty sure the root cause is how the current Python implementation assumes certain Twitch responses are always present, instead of defensively handling the cases where Twitch returns null / missing data.
All of the stack traces here fall into the same pattern: TypeError: 'NoneType' object is not subscriptable in Twitch.py happens when fields like response["data"]["user"]["stream"] or channel["self"]["communityPoints"] are None, but the code still tries to index into them.
requests.exceptions.MissingSchema: Invalid URL 'None' in send_minute_watched_events happens when stream.spade_url is None and requests.post is called with that value as the URL.
In my Go recode of the miner I’ve fixed exactly these failure modes by treating “missing Twitch data” as a first‑class, expected condition instead of an exception.
For stream info: if data.user.stream is missing, the Go version returns a dedicated “streamer offline” error and marks the streamer as offline; if data.user is missing, it returns a clear error instead of indexing into None. For channel points: if data.community.channel is missing, it returns a clear error and effectively skips that streamer; if communityPoints fields are missing or malformed, it safely falls back to 0 points instead of crashing. For spade_url: the code first resolves the URL from the Twitch page; if it can’t be found, it returns an error and never calls the “minute watched” endpoint with a None/empty URL. The main loop treats all of these as recoverable errors (offline, temporary network issues, missing data), logs them, and continues mining instead of stopping silently while the process stays open. You can see the recoded implementation here, which runs stably under exactly the same Twitch behavior that currently breaks the Python version: https://github.com/0x8fv/Twitch-Channel-Points-Miner
In short: the Python errors are not really “new Twitch behavior” problems, but missing None / error handling around Twitch’s GQL and web responses. The Go port adds those guards everywhere, and as a result it doesn’t hit the catastrophic crashes described in this issue.

It sounds great and beautiful, but:

1. I have no idea what "Go" is.
2. Is "Go" a programming language? And you used it to write a complete clone of what we have here in Python?
3. Do you have multi-accounting capabilities?
4. How much more difficult is using your software than this one?
5. Is it possible to migrate existing cookies/script executables to run in Go?

After so many years of working on the Python version, if porting isn't possible, it will be extremely problematic to use.
If you had the advantage of a fully-fledged multi-accounting version, you could try, but without migrating existing accounts, it's an incredible waste of time and effort.

Yes, Go is a programming language. This repo is a Go rewrite of the Python miner with very similar behavior (auto‑claims bonuses, drops, predictions, raids, etc.).

Multi‑account works the same way as the Python version: each account has its own cookie file in the cookies folder, and you switch accounts simply by changing the username in config.json. There’s no automatic migration of Python cookies or .exe builds. Each account needs one device login in the Go version to create its cookie, but after that you can swap between them just by changing username in config.json.

Usage is very similar: edit config.json and run it. You can either just run the provided executable (no Go installed, no Python, no virtualenv), or, if you prefer, install Go and run/build it yourself (go run . / go build).

Based on your run.py settings this should roughly translate to this config.json in the Go version:

{
"username": "YOUR_TWITCH_USERNAME",
"auto_update": true,
"debug": false,
"smart_logging": true,
"disable_ssl_cert_verification": false,
"show_seconds": false,
"claim_drops_startup": true,
"claim_drops": true,
"betting(make_predictions)": false,
"follow_raid": false,
"community_goals": false,
"emojis": true,
"save_logs": false,
"show_username_in_console": false,
"show_claimed_bonus_msg": false,
"streamers": [
"STREAMER_FOR_LOOTING_1",
"STREAMER_FOR_LOOTING_2"
],
"watch_priority": [
"STREAK",
"DROPS",
"ORDER"
],
"password": "your-twitch-password (Optional)",
"bet": {
"strategy": "SMART",
"percentage": 5,
"percentage_gap": 20,
"max_points": 50000,
"stealth_mode": true,
"delay_mode": null,
"delay": null,
"minimum_points": null
}
}
If you have any other questions about my go script how ever please create a Threat on my repository...

For some reason, the miner's console just won't open when I copy the streamer.

[Ewcounless]

But I encountered a catastrophic error where looting didn't even start. The same error I called "purple."

@Ewcounless

The "purple" errors are actually just how the console formats parts of python stack traces. A stack trace being a sort of history of the code being run to reach the error. The stack trace can show up for any type of error, not just these ones. So, the fact that the errors are "purple" doesn't mean they're related.

There's a debug log, but no regular log. I was hasty and accidentally closed the script :)
Debug log: https://gist.github.com/Ewcounless/8e4c4fd9a6955053c1feab838de441ed#file-gistfile1-txt
Is that enough now? Are your thoughts confirmed?

Oh thanks! I can see in there that this is indeed a service timeout issue. You have 2 VideoPlayerStreamInfoOverlayChannel requests in there and one returns normally, but the other returns a response with and errors field containing a service timeout. I can also see that earlier requests for both, getting their user ids, users succeed. This confirms to me that the issue is Twitch side and we just need better handling for GQL responses.

Did you read the message from 0x8fv where he gave his detailed opinion regarding my mistakes? Do you think his reasoning is incorrect?

Regarding your last answer, am I correct in understanding that your previous assumptions were only confirmed after viewing my latest debug log?

[mpforce1]

Did you read the message from 0x8fv where he gave his detailed opinion regarding my mistakes? Do you think his reasoning is incorrect?

I read their message and I agree with their assessment. What they've said is not substantially different from anything I've already said, although they gave some nice context from their experience writing and using the go miner (cool stuff btw).

Regarding your last answer, am I correct in understanding that your previous assumptions were only confirmed after viewing my latest debug log?

Yes.

FYI, I have completed the majority of the work for a complete rework of the GQL layer, it's currently pushed up to PR #759 (this is unfinished so don't try and use it yet). I'm just asking for feedback from the community on my approach before doing the rest. This should, hopefully, drastically reduce the number of logged errors you get when making GQL requests. It will not fix, for example, the PubSub WebSocket errors, nor will it fix the "spade url" errors. Although, I might have a look at that last one if I have time.