Closed acocuzzo closed 1 year ago
Followup q from: @gzamb
I'm seeing the same thing as @sls-cat. Here are my dependencies:
Package Version --------------------------------- --------- astroid 2.8.2 attrs 21.2.0 backports.entry-points-selectable 1.1.0 bitarray 2.3.4 black 21.9b0 CacheControl 0.12.11 cachetools 4.2.4 cachy 0.3.0 certifi 2021.10.8 cfgv 3.3.1 charset-normalizer 2.0.7 cleo 0.8.1 click 8.0.3 clikit 0.6.2 coverage 6.0.2 crashtest 0.3.1 datadog 0.42.0 ddtrace 0.54.0 dependency-injector 4.36.2 distlib 0.3.3 dotenv-cli 2.2.0 filelock 3.3.0 google-api-core 2.7.3 google-auth 2.3.0 google-cloud-bigquery 3.0.1 google-cloud-bigquery-storage 2.13.1 google-cloud-core 2.1.0 google-cloud-pubsub 2.12.1 google-cloud-spanner 3.11.1 google-crc32c 1.3.0 google-resumable-media 2.0.3 googleapis-common-protos 1.53.0 grpc-google-iam-v1 0.12.3 grpcio 1.46.3 grpcio-status 1.41.0 html5lib 1.1 httpretty 1.1.4 identify 2.3.0 idna 3.2 importlib-metadata 4.11.4 iniconfig 1.1.1 isort 5.9.3 keyring 23.5.1 lazy-object-proxy 1.6.0 lockfile 0.12.2 mccabe 0.6.1 msgpack 1.0.4 mypy-extensions 0.4.3 nodeenv 1.6.0 numpy 1.22.3 packaging 21.0 pastel 0.2.1 pathspec 0.9.0 pexpect 4.8.0 pip 22.1.2 pkginfo 1.8.2 platformdirs 2.4.0 pluggy 1.0.0 poetry 1.1.13 poetry-core 1.0.8 powlet 2.10.1 pre-commit 2.15.0 proto-plus 1.19.5 protobuf 3.18.1 ptyprocess 0.7.0 py 1.10.0 pyarrow 7.0.0 pyasn1 0.4.8 pyasn1-modules 0.2.8 pylev 1.4.0 pylint 2.11.1 pyparsing 2.4.7 pytest 6.2.5 pytest-cov 2.12.1 pytest-mock 3.6.1 python-dateutil 2.8.2 python-dotenv 0.20.0 python-json-logger 2.0.2 PyYAML 5.4.1 regex 2021.10.8 requests 2.26.0 requests-toolbelt 0.9.1 rsa 4.7.2 setuptools 62.1.0 shellingham 1.4.0 six 1.16.0 sqlparse 0.4.2 tenacity 8.0.1 toml 0.10.2 tomli 1.2.1 tomlkit 0.11.0 typing-extensions 3.10.0.2 urllib3 1.26.7 virtualenv 20.8.1 webencodings 0.5.1 wheel 0.37.1 wrapt 1.12.1 zipp 3.8.0
I was previously on v2.8 on python3.9 and it worked fine.
I am having the exact same issue. In my case, I’m working on an issue in the Home Assistant Nest Integration effecting hundreds of users.
https://www.home-assistant.io/integrations/nest/ https://github.com/home-assistant/core/issues/70479
The issue is, that when Home Assistant loses connection to the google cloud (home internet outage, LAN failure, etc), there is no notification to the client that the connection has failed AND home assistant continues to believe it is connected and displays stale data for the NEST thermostats - leading the user to believe all is well with their home heating system.
If I override this constant in streaming_manager.py then the stream closes and callback gets called.
streaming_pull_manager._RETRYABLE_STREAM_ERRORS = ()
But overriding a private member is not a good solve. What would be best is if we could pass a “Retry” object into the client, In which we could allow x number of auto-retries (current behavior) before failing it (desired new behavior.). Similar to what is described here: https://cloud.google.com/python/docs/reference/storage/1.39.0/retry_timeout#configuring-retries
Alternatively, if there is way to accomplish this with the existing API, that would be even better!
2022-10-02 10:18:16.226 INFO (Thread-10 (_run)) [google.api_core.bidi] Re-established stream
2022-10-02 10:18:16.226 DEBUG (Thread-10 (_run)) [google.cloud.pubsub_v1.subscriber._protocol.streaming_pull_manager] Observed non-terminating stream error 503 failed to connect to all addresses; last error: UNKNOWN: Network is unreachable
2022-10-02 10:18:16.226 DEBUG (Thread-10 (_run)) [google.cloud.pubsub_v1.subscriber._protocol.streaming_pull_manager] Observed recoverable stream error 503 failed to connect to all addresses; last error: UNKNOWN: Network is unreachable
2022-10-02 10:18:16.227 DEBUG (Thread-10 (_run)) [google.api_core.bidi] Re-opening stream from gRPC callback.
2022-10-02 10:18:16.232 INFO (Thread-10 (_run)) [google.api_core.bidi] Re-established stream
2022-10-02 10:18:16.233 DEBUG (Thread-ConsumeBidirectionalStream) [google.api_core.bidi] Call to retryable <bound method ResumableBidiRpc._recv of <google.api_core.bidi.ResumableBidiRpc object at 0x7f4ba7f450c0>> caused 503 failed to connect to all addresses; last error: UNKNOWN: Network is unreachable.
2022-10-02 10:18:16.233 DEBUG (Thread-ConsumeBidirectionalStream) [google.cloud.pubsub_v1.subscriber._protocol.streaming_pull_manager] Observed non-terminating stream error 503 failed to connect to all addresses; last error: UNKNOWN: Network is unreachable
2022-10-02 10:18:16.233 DEBUG (Thread-ConsumeBidirectionalStream) [google.cloud.pubsub_v1.subscriber._protocol.streaming_pull_manager] Observed recoverable stream error 503 failed to connect to all addresses; last error: UNKNOWN: Network is unreachable
2022-10-02 10:18:16.234 DEBUG (Thread-ConsumeBidirectionalStream) [google.api_core.bidi] Re-opening stream from retryable <bound method ResumableBidiRpc._recv of <google.api_core.bidi.ResumableBidiRpc object at 0x7f4ba7f450c0>>.
2022-10-02 10:18:17.681 DEBUG (Thread-LeaseMaintainer) [google.cloud.pubsub_v1.subscriber._protocol.leaser] The current deadline value is 10 seconds.
2022-10-02 10:18:17.682 DEBUG (Thread-LeaseMaintainer) [google.cloud.pubsub_v1.subscriber._protocol.leaser] Snoozing lease management for 6.052412 seconds.
2022-10-02 10:18:23.735 DEBUG (Thread-LeaseMaintainer) [google.cloud.pubsub_v1.subscriber._protocol.leaser] The current deadline value is 10 seconds.
2022-10-02 10:18:23.735 DEBUG (Thread-LeaseMaintainer) [google.cloud.pubsub_v1.subscriber._protocol.leaser] Snoozing lease management for 8.714147 seconds.
2022-10-02 10:18:26.201 INFO (Thread-ConsumeBidirectionalStream) [google.api_core.bidi] Re-established stream
For your specific use case, I'm wondering if your "staleness" issue could be solved by checking the age of the last processed message. Is this a possible fix for your specific case?
Changing this to a feature request, and moving to: https://issuetracker.google.com/issues/269679604 This will ensure that the fix can happen across client libraries.
From @sls-cat comment:
504
Is there any hints as to what causes this? Having an application go into infinite error scroll like this is not helpful. I would except a certain number of reconnect attempts and then failure, instead of an infinite look up reconnect attempts. This has been attempting reconnects for a week now.
I see it started with this, which appears to have some issues in the SDK: