chore(deps): consolidated dependency bump - #3108
Merged
Merged
Conversation
Combine six open Dependabot PRs into one bump and regenerate both lockfiles so they resolve together: - requests 2.33.1 -> 2.34.2 (#3098) - ansible-core 2.21.0 -> 2.21.1 (#3097) - redis 7.4.0 -> 8.0.1 (#3096) - djangorestframework-stubs 3.16.9 -> 3.17.0 (#3095) - django-stubs-ext 6.0.5 -> 6.0.6 (#3094) - tailwindcss + @tailwindcss/cli 4.3.1 -> 4.3.2 (#3104) redis is a major bump. kombu 5.6.2 caps its optional redis extra at <6.5, but we depend on redis-py directly, so the cap is not enforced. Verified against a live redis that the direct client API (get/set/ rpush/blpop/pubsub), the celery->redis broker enqueue path, and the channels-redis channel layer all work with redis-py 8.0.1. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
There was a problem hiding this comment.
Pull request overview
This PR consolidates multiple Dependabot updates into a single dependency bump across the Python and Bun ecosystems, updating declared dependency pins and regenerating both lockfiles so resolution is consistent.
Changes:
- Bump Python dependencies (requests, redis, ansible-core, django-stubs-ext, djangorestframework-stubs) and regenerate
uv.lock. - Bump Tailwind packages and regenerate
bun.lock. - Update
pyproject.tomlandpackage.jsonto reflect the new versions.
Reviewed changes
Copilot reviewed 2 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
uv.lock |
Regenerated UV lockfile reflecting bumped Python dependency versions. |
pyproject.toml |
Updates pinned Python dependency versions in dependency groups. |
package.json |
Bumps Tailwind-related devDependencies to ^4.3.2. |
bun.lock |
Regenerated Bun lockfile reflecting Tailwind package updates. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Address Copilot review on the consolidated bump: - Bump the hardcoded requests pin in build-balena-disk-image.yaml (rpi-imager.json generation) to 2.34.2 to match pyproject. - requests 2.34.2 now ships py.typed, so the types-requests stub in the dev-host group is redundant; remove it and relock. The inline types are stricter and surfaced a latent bytes/str inconsistency in handle_github_error's errdesc, now annotated as bytes | str. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
The build-rpi-imager-json job installed requests with a hardcoded `pip install 'requests==X'`, a pin that had to be hand-synced with pyproject.toml (and had already drifted). Replace it with the pinned astral-sh/setup-uv action and `uv run --locked --group local`, which resolves requests from uv.lock and fails the job if pyproject and the lockfile ever diverge. Removes the drift source permanently. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
jq empty asserts the file is well-formed JSON and exits non-zero on failure without dumping the payload to the build log; jq . only pretty-printed it as a side effect of parsing. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
handle_github_error logged exc.response.content (bytes), which renders as a b'...' repr in the log line. Use .text so the GitHub error body reads as the server's actual message and errdesc stays a plain str. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
|
This was referenced Jul 2, 2026
vpetersson-bot
added a commit
to vpetersson-bot/Anthias
that referenced
this pull request
Jul 30, 2026
Fixes Screenly#3228. On an open WebSocket the server logged, every ~5s: redis.exceptions.TimeoutError: Timeout reading from redis:6379 ERROR: Exception in ASGI application Root cause: redis-py 8.0.1 (bumped from 7.4.0 in Screenly#3108) introduced a default 5-second async socket read timeout (DEFAULT_SOCKET_TIMEOUT = 5; 7.4.0 had none). channels_redis polls each channel with a blocking BZPOPMIN whose server-side timeout is brpop_timeout = 5s. With no override the blocking read inherits the 5s socket timeout, so an empty poll that legitimately blocks the full 5s races the socket read timeout and raises -- on every poll cycle, for any connected WebSocket. Not config drift and not board-specific; reproduces on healthy redis on any install running v2026.7.4 whenever the web UI is open. Fix: set the channel-layer connection socket_timeout to 15s -- above the 5s blocking poll so it can't race, while still bounding a genuinely dead redis connection (rather than disabling the read timeout entirely). Message delivery is unaffected. Reproduced and verified: an idle channel-layer receive() raised the exact error under redis-py 8.0.1 (DEFAULT_SOCKET_TIMEOUT=5) and now blocks cleanly with socket_timeout=15; bisected to redis-py 7.4.0 (clean) vs 8.0.1 (broken). test_consumers + test_messaging pass; full non-integration suite green (1513). Co-Authored-By: Claude Opus 4.8 <[email protected]> Claude-Session: https://claude.ai/code/session_01HJ3ucEkn62cbgPoisAZ5LQ
vpetersson-bot
added a commit
to vpetersson-bot/Anthias
that referenced
this pull request
Jul 30, 2026
Fixes Screenly#3228. On an open WebSocket the server logged, every ~5s: redis.exceptions.TimeoutError: Timeout reading from redis:6379 ERROR: Exception in ASGI application Root cause: redis-py 8.0.1 (bumped from 7.4.0 in Screenly#3108) introduced a default 5-second async socket read timeout (DEFAULT_SOCKET_TIMEOUT = 5; 7.4.0 had none). channels_redis polls each channel with a blocking BZPOPMIN whose server-side timeout is brpop_timeout = 5s. With no override the blocking read inherits the 5s socket timeout, so an empty poll that legitimately blocks the full 5s races the socket read timeout and raises -- on every poll cycle, for any connected WebSocket. Not config drift and not board-specific; reproduces on healthy redis on any install running v2026.7.4 whenever the web UI is open. Fix: set the channel-layer connection socket_timeout to 15s -- above the 5s blocking poll so it can't race, while still bounding a genuinely dead redis connection (rather than disabling the read timeout entirely). Message delivery is unaffected. Reproduced and verified: an idle channel-layer receive() raised the exact error under redis-py 8.0.1 (DEFAULT_SOCKET_TIMEOUT=5) and now blocks cleanly with socket_timeout=15; bisected to redis-py 7.4.0 (clean) vs 8.0.1 (broken). test_consumers + test_messaging pass; full non-integration suite green (1513). Co-Authored-By: Claude Opus 4.8 <[email protected]> Claude-Session: https://claude.ai/code/session_01HJ3ucEkn62cbgPoisAZ5LQ
vpetersson
pushed a commit
that referenced
this pull request
Jul 30, 2026
…#3229) Fixes #3228. On an open WebSocket the server logged, every ~5s: redis.exceptions.TimeoutError: Timeout reading from redis:6379 ERROR: Exception in ASGI application Root cause: redis-py 8.0.1 (bumped from 7.4.0 in #3108) introduced a default 5-second async socket read timeout (DEFAULT_SOCKET_TIMEOUT = 5; 7.4.0 had none). channels_redis polls each channel with a blocking BZPOPMIN whose server-side timeout is brpop_timeout = 5s. With no override the blocking read inherits the 5s socket timeout, so an empty poll that legitimately blocks the full 5s races the socket read timeout and raises -- on every poll cycle, for any connected WebSocket. Not config drift and not board-specific; reproduces on healthy redis on any install running v2026.7.4 whenever the web UI is open. Fix: set the channel-layer connection socket_timeout to 15s -- above the 5s blocking poll so it can't race, while still bounding a genuinely dead redis connection (rather than disabling the read timeout entirely). Message delivery is unaffected. Reproduced and verified: an idle channel-layer receive() raised the exact error under redis-py 8.0.1 (DEFAULT_SOCKET_TIMEOUT=5) and now blocks cleanly with socket_timeout=15; bisected to redis-py 7.4.0 (clean) vs 8.0.1 (broken). test_consumers + test_messaging pass; full non-integration suite green (1513). Claude-Session: https://claude.ai/code/session_01HJ3ucEkn62cbgPoisAZ5LQ Co-authored-by: vpetersson-bot <[email protected]> Co-authored-by: Claude Opus 4.8 <[email protected]>
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
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.
Combines the six open Dependabot PRs into a single bump and regenerates both lockfiles (
uv.lock,bun.lock) so they resolve together.Bumps
redis major bump (7 → 8)
kombu5.6.2 caps its optionalredisextra at<6.5, but we depend on redis-py directly so that cap is not enforced. Verified against a live redis that redis-py 8.0.1 works for every way the codebase uses it:get/set/rpush/blpop/pubsubround-tripchannels-redischannel layer that backs the WebSocket endpointTesting
uv run ruff check .andruff format --check .— cleanuv run pytest -m "not integration"— 1147 passedThe six superseded Dependabot PRs (#3094, #3095, #3096, #3097, #3098, #3104) have been closed in favour of this one.
🤖 Generated with Claude Code