fix: fail startup on an unreachable Redis, and count translated errors as errors - #23
Merged
Merged
Conversation
…s as errors The work landed in #22. Its squash subject lost the Conventional Commit prefix -- my mistake on the merge, not the author's -- so release-please skipped the merge and these fixes would never have reached a release. This commit carries the record. It changes no code: #22 is already on master. * retry_async_connection could not fail startup. It raised only when connect_func raised, while the health check returned False instead of raising, so the loop spun three times with no backoff and handed back a client that could not reach Redis. A falsy result is a retried failure now and the last attempt raises. Reproduced against a dead port. * AsyncRedisProvider.get_redis was unreachable: it and get_redis_with_health_check provided the same dishka key and the second won. The choice moved to a constructor flag and both methods are reachable. * Provider order was load-bearing and silent: the Redis provider supplied a None metrics collector, so registered after a metrics provider it overrode it and you got a plain client with no error. A flag turns the default off. * The async instrumented client read pool._all_connections, which redis-py 8 does not have, so the pool-size gauge was always zero. It sums the two attributes the sync client already used. * In all four clients the RuntimeError branch preceded the one that sets an error status, so a uvloop transport error translated to ConnectionError was counted as a success and never recorded. * The three guide pages and the docs home documented a settings API that does not exist -- every snippet raised a validation error -- along with OpenTelemetry support, a wrong redis floor, a wrong Python floor and an extra that is not declared. All corrected against the code.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No code changes. One empty commit restoring a record the merge of #22 lost.
I squash-merged #22 using its pull request title as the commit subject, and that title was written as prose rather than as a Conventional Commit. release-please parses subjects, found nothing releasable since the last tag, and opened no release pull request — so the fixes would have sat on
masterindefinitely. My mistake on the merge, not the author's.The commit message here carries the same summary under a
fix:subject, so the pending release is computed and the changelog says what changed. The full detail, the reproductions and the tests are in #22.The diff is empty by design. Reviewing it means reading #22.