[dependabot]

Bumps django-health-check from 4.0.6 to 4.8.0.

Release notes

Sourced from django-health-check's releases.

4.8.0

What's Changed

• Add npm status page check by @​codingjoe in codingjoe/django-health-check#794
• Add PyPI status check by @​codingjoe in codingjoe/django-health-check#793
• Fix #747 -- Log failed health checks at warning level by @​codingjoe in codingjoe/django-health-check#796

Full Changelog: codingjoe/django-health-check@4.7.2...4.8.0

4.7.2

What's Changed

• Bound every check probe by its own timeout by @​codingjoe in codingjoe/django-health-check#789

Full Changelog: codingjoe/django-health-check@4.7.1...4.7.2

4.7.1

What's Changed

• Choose static defaults and update docs w/ more specific instructions by @​codingjoe in codingjoe/django-health-check#787

Full Changelog: codingjoe/django-health-check@4.7.0...4.7.1

4.7.0

What's Changed

• Add a django-crontask scheduler health check by @​codingjoe in codingjoe/django-health-check#782
• Add a threadmill task queue health check by @​codingjoe in codingjoe/django-health-check#783
• Fix #781 -- Remove unrelated AWS sentence above the contrib extras install by @​codingjoe in codingjoe/django-health-check#784
• Fix #780 -- Cover the Redis unknown-client fallback in tests by @​codingjoe in codingjoe/django-health-check#785
• Fix #779 -- Redact RabbitMQ broker credentials from repr, labels and logs by @​codingjoe in codingjoe/django-health-check#786

Full Changelog: codingjoe/django-health-check@4.6.1...4.7.0

4.6.1

What's Changed

• Always display default nameservers by @​codingjoe in codingjoe/django-health-check#775

Full Changelog: codingjoe/django-health-check@4.6.0...4.6.1

4.6.0

What's Changed

• Make DNS check record type configurable by @​codingjoe in codingjoe/django-health-check#773
• Add never cache headers w/o decorator by @​codingjoe in codingjoe/django-health-check#774

Full Changelog: codingjoe/django-health-check@4.5.1...4.6.0

... (truncated)

Commits

• 0d17159 Fix #747 -- Log failed health checks at warning level (#796)
• 0fa2a29 Add PyPI status check (#793)
• 0984937 Add npm status page check (#794)
• 0b93c39 Bound every check probe by its own timeout (#789)
• aec2712 Choose static defaults and update docs w/ more specific instructions (#787)
• 9576ac7 Fix #779 -- Redact RabbitMQ broker credentials from repr, labels and logs (#786)
• 7aaa4d4 Fix #780 -- Cover the Redis unknown-client fallback in tests (#785)
• deac77d Fix #781 -- Remove unrelated AWS sentence above the contrib extras install (#...
• b345ac3 Add a threadmill task queue health check (#783)
• e3c18ed Add a django-crontask scheduler health check (#782)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[claude]

🔍 Dependency Analysis Summary

Package	Old	New	Type
django-health-check	4.0.6	4.8.0	minor (lockfile only, no pyproject.toml change)

Overall risk: MEDIUM. The upgrade breaks no API we use, but 4.7.2 adds a time limit around every check, and that limit applies to our custom CeleryQueueCheck. In some cases the check will now report a Celery queue as down when the old code would have passed it (details below).

📋 Detailed Changelog Review

django-health-check (4.0.6 → 4.8.0)

• 4.4.0: Public dataclass fields are exposed as OpenMetrics labels. CeleryQueueCheck excludes app and timeout from repr, so only label and queue appear as labels.
• 4.4.4: Redis label added to the JSON views.
• 4.5.0: Mail check supports the Django 6.1 MAILERS setting (we don't use the mail check).
• 4.6.0: DNS record type is configurable. Cache-control headers are now set without a decorator.
• 4.7.0: New crontask and threadmill checks. RabbitMQ credentials are redacted from logs.
• 4.7.2 — behaviour change (#789): "Bound every check probe by its own timeout." HealthCheck gains a class default timeout = timedelta(seconds=5). get_result() now wraps run() in asyncio.wait_for(..., self.timeout.total_seconds() + 1), and on expiry reports ServiceUnavailable("Timed out after N seconds").
• 4.8.0: npm and PyPI status-page checks. Failed checks are now logged at WARNING level through the health_check logger (Bump actions/setup-node from 3 to 4 #747).
• Breaking changes: none to the APIs we import (health_check.base.HealthCheck, health_check.exceptions.ServiceUnavailable, health_check.views.HealthCheckView, health_check.checks.Database/Cache, health_check.contrib.redis.Redis(client_factory=...)).
• Security: only the RabbitMQ credential redaction (4.7.0), which doesn't affect us.

⚠️ Impact Assessment

Behaviour change affecting apps/web/health_checks.py (CeleryQueueCheck)

CeleryQueueCheck declares its own timeout = 3s, so the new library limit for the whole check is 3 + 1 = 4 s. But that 3 s is meant as the budget for each of two broadcast RPCs that run one after the other (see the comment on the field):

1. inspect(timeout=3).active_queues() has no destination, so kombu has no reply limit and always waits the full 3 s (kombu/pidbox.py:343).
2. ping(destination=workers_on_queue, timeout=3) returns early only when every listed worker replies. If even one is slow or gone, it waits up to the full 3 s.

So:

• Healthy case: about 3 s + ping round-trip. That leaves less than 1 s of margin against the 4 s limit. Any broker slowness over that margin now fails the check.
• During a deploy, active_queues can still list an old worker that is shutting down. ping then waits the full 3 s, for about 6 s in total. With 4.0.6 the check passed, because any(...) accepts one healthy reply. With 4.8.0 it fails at 4 s with Timed out after 3 seconds. That is a false failure on the celery / queue-* health endpoints, during exactly the window the field's comment says needs headroom. If uptime monitoring or orchestration watches those endpoints, it would alert or restart.
• Also, wait_for on run_in_executor cannot stop the worker thread. A check that times out keeps running in the background until its RPCs return.

Other effects

• Database, Cache and Redis checks now get the 5 s default limit. No problem expected.
• Failed checks now emit WARNING logs (with traceback) through the health_check logger. If probes run often while something is down, this can add log and Sentry noise. Check the logging config if needed.
• Tests: apps/web/tests/test_health_checks.py mocks the Celery control calls, so it will most likely still pass and won't catch the timeout change. I couldn't run it locally (no env configured); CI is the authority here.
• Configuration: no settings changes are required.

🛠️ Recommendations

Action required (small): make CeleryQueueCheck fit the new overall limit. Either:

• set the class timeout to the overall budget and split it between the two RPCs (e.g. timeout=6s and call each RPC with timeout / 2), or
• keep the per-RPC value in a separately named field (e.g. rpc_timeout = 3s) and set timeout = 2 * rpc_timeout.

Add a test that patches the two RPCs to sleep and checks that get_result() still reports the specific "No worker…" message, not "Timed out".

Testing focus: hit /health/ with the celery and queue-* subsets against a running worker, and again while restarting a worker, and check response times and status.

Merge recommendation: REVIEW_NEEDED. The upgrade is safe API-wise. Merge it together with the CeleryQueueCheck timeout adjustment, or right after it, so the Celery endpoints don't report false failures during deploys.

📚 Useful Links

• Releases: https://github.com/codingjoe/django-health-check/releases
• Per-check timeout PR: Bound every check probe by its own timeout codingjoe/django-health-check#789
• HealthCheck.get_result at 4.8.0: https://github.com/codingjoe/django-health-check/blob/4.8.0/health_check/base.py