Repository navigation
Next release: Vale of White Horse, Sunderland, Bolsover, Solihull, Exeter fixes + config redaction - #2241
Merged
Conversation
Bumps [docker/login-action](https://github.com/docker/login-action) from 4.5.2 to 4.6.0. - [Release notes](https://github.com/docker/login-action/releases) - [Commits](docker/login-action@v4.5.2...v4.6.0) --- updated-dependencies: - dependency-name: docker/login-action dependency-version: 4.6.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [github/codeql-action](https://github.com/github/codeql-action) from 4.37.4 to 4.38.1. - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](github/codeql-action@v4.37.4...v4.38.1) --- updated-dependencies: - dependency-name: github/codeql-action dependency-version: 4.38.1 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
…oliday or Christmas week The page publishes the current fortnight's pair of collections rather than the next occurrence of each bin, so a past date is rolled forward by 14 days. That's wrong when the roll-forward lands in a week the council collects on a different day - which only the page knows. Skip publishing a guess for a bank-holiday week (checked with the existing is_holiday()) or the 24 Dec-17 Jan slippage period, where the council's leaflet shows collections running one to two days late well past the last holiday. Also fixes a separate bug: the page carries no year, so in early January it still shows the current fortnight's December date, which parsed as this year's December was returned as eleven months away. A page date more than six months ahead is now read as last year's. Credit: dpage (#2229). Follows up on #2213.
…hallenge Since mid-September 2026 the council's site serves a Cloudflare managed challenge (cf-mitigated: challenge) on every page to clients whose TLS fingerprint doesn't look like a browser - plain requests/curl get 403 regardless of headers, source IP, or User-Agent. The form itself is still a plain HTML postback wizard needing no JavaScript execution, so driving it through a curl_cffi session that impersonates Chrome's TLS handshake is sufficient. Adds curl_cffi as a dependency (ships manylinux/musllinux wheels, so it installs without a compiler on the HA Alpine image too). Credit: jonny190 (#2233). Fixes #2232.
… relative week number The scraper computed which bin type (Black, or Burgundy+Green) is collected on a date using a week index (1-4) positioned relative to "today". The same calendar date could get different parities on consecutive runs, and the phase didn't reliably survive ISO week-53 year boundaries. Anchor to a fixed epoch (2024-01-08, the Monday found by testing against the council's published calendar to match their "Week 1" phase) and derive parity from a continuous fortnight count from there, so consecutive weeks always alternate regardless of when the scraper runs or where a year boundary falls. Verified against Bolsover's published calendar B (UPRN 100030066827): confirmed Black Bin on 22/09/2026, Burgundy+Green on 29/09/2026. Credit: JoeGandy (#2236).
…stics Home Assistant config-flow and setup logs previously included complete config dictionaries and CLI argument values at debug/info level - postcodes, UPRNs, house numbers, private council/Selenium URLs, and user-supplied names. Those records are often collected for HA diagnostics and shared outside the local installation. Adds redact_config_data(), applied everywhere a config dict or Selenium URL was logged, and drops raw UKBCD argument values from logs in favour of an argument count. Config-flow behavior is unchanged; only what reaches the logs is affected. Credit: dajiaohuang (#2239).
This was referenced Sep 24, 2026
Contributor
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. Note Currently processing new changes in this PR. This may take a few minutes, please wait... ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (15)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
❌ 2 Tests Failed:
View the full list of 2 ❄️ flaky test(s)
To view more test analytics, go to the Test Analytics Dashboard |
A bin card with no collection history yet (e.g. a newly added food caddy) renders only the "Next collection" row instead of both "Last collected" and "Next collection", so the fixed div.mt-1[1] index went out of range (#2235). Read the last of whichever date rows are present instead, and skip a card with none rather than crashing. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015MaCS29izthZp2dwtvLwf4
Dumps step timings and, when the collection table comes back empty, the raw HTML fragment and table candidates found in it. Sandbox network access can't reach the council's site directly, so this rides the live integration-test CI job to gather what's actually changed. Will be removed once the real fix lands. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015MaCS29izthZp2dwtvLwf4
… stage The council retired the "Beta" API stage this scraper called; it now 403s unconditionally regardless of the uprn/usrn payload sent, matching what was reported in #2215. Their own front end now calls the "prod" stage of the same API instead (confirmed via a fix another open-source waste-collection project independently landed for the same endpoint), so switch to that, add the Origin/Referer headers their site sends, and drop the now-redundant extra json.loads of the "dates" field the prod stage already returns as a proper object. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015MaCS29izthZp2dwtvLwf4
The live integration test on this branch shows the curl_cffi Chrome impersonation from #2233 still gets a 403 on the very first GET, not later in the form flow. Dumping the response status, headers (looking for cf-mitigated) and a body snippet via the live CI job to see whether Cloudflare has moved to a JS challenge that a TLS-fingerprint fix alone can't pass. Will be removed once the real fix lands. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015MaCS29izthZp2dwtvLwf4
…sonation
Matches the pattern already used for Gateshead and Powys (the same
GOSS iCM platform, also Cloudflare-fronted): Cloudflare scores on
header completeness/IP reputation alongside TLS fingerprint, so a
curl_cffi Chrome impersonation with only a bare User-Agent is weaker
evidence than it needs to be. Also documents the known, unfixable-in-
client limitation that a flagged datacenter IP (e.g. a CI runner) can
still get challenged regardless - this live branch's own CI run hit
exactly that ("cf-mitigated: challenge", a Turnstile interstitial)
even with the TLS impersonation from #2233 already in place.
Also adds temporary diagnostics to Canterbury's still-failing 403 on
the new "prod" endpoint, to see whether it's the same kind of
IP-reputation block or a genuine remaining payload/response mismatch.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015MaCS29izthZp2dwtvLwf4
The "prod" endpoint swap (from a720e4e) doesn't actually fix #2215 - this branch's own live CI shows a clean AWS API Gateway ForbiddenException ({"message":"Forbidden"}, via CloudFront) on the prod endpoint too, not a bot/Cloudflare-style challenge. Comparing against another open-source project's working implementation of the same API shows why: their collection call sends a real uprn+usrn pair obtained from a postcode+house-number address lookup (trsewmllv7.execute-api.../dev/address), not a hardcoded usrn="1". This scraper currently only accepts a UPRN (no postcode/house number), so matching that flow means changing this scraper's expected inputs - a breaking change for existing users, not a same-shape fix. Reverting to the pre-existing behaviour (a clear, honest 403 error) rather than shipping an endpoint change that doesn't resolve the issue; the real fix is a larger, separate piece of work, flagged on #2215. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015MaCS29izthZp2dwtvLwf4
The live CI run confirmed the scraper works against the real site unmodified - #2238/#2228 look transient rather than a code defect (commented on both issues). Removing the diagnostic prints now that they've served their purpose; file is back to its pre-diagnostic state. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015MaCS29izthZp2dwtvLwf4
…uest #2240 reports a 403 from this endpoint, while the reporter could load the council's site fine in an ordinary browser - the request currently sends no headers at all (not even a User-Agent), which points at bot/fingerprint detection rather than an outage. Adds the same kind of realistic header set already used for other councils behind similar protection (Gateshead, Powys). Also adds temporary diagnostics on the UPRN-lookup path (the one the traceback in #2240 hit) to confirm via live CI whether this actually clears the block. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015MaCS29izthZp2dwtvLwf4
Live CI still gets a 403 with the realistic headers in place, but it's a plain Microsoft-Azure-Application-Gateway static error page - not a bot-challenge or a payload-validation error - which matches the same flagged-datacenter-IP pattern already documented for Sunderland in this same release. Keeping the header fix (strictly better than sending no headers at all) but noting real-world verification has to come from an actual deployment, not this CI environment. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015MaCS29izthZp2dwtvLwf4
4 tasks done
This was referenced Sep 24, 2026
5 tasks done
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.
Summary
Consolidates the vetted open PRs into the next release, tested together on one branch.
curl_cffiimpersonating Chrome and, matching the existing pattern for Gateshead/Powys (same GOSS iCM platform, also Cloudflare-fronted), sends a complete browser-like header set rather than just a User-Agent. Not conclusively verifiable from this branch's own CI: the live integration run still gets Cloudflare's challenge page (cf-mitigated: challenge), which matches a known, already-documented limitation for these councils — Cloudflare's IP reputation scoring flags GitHub-hosted runner IPs regardless of client sophistication (see the comment already inPowysCouncil.py/GatesheadCouncil.py). Real-world verification will need to come from an actual deployment. (from fix(councils): use curl_cffi for SunderlandCityCouncil to pass Cloudflare TLS fingerprint challenge #2233, credit @jonny190, targets SunderlandCityCouncil: 403 from Cloudflare TLS fingerprint challenge since 15 Sep 2026 (curl_cffi fix tested) #2232)Investigated but not included
ForbiddenExceptionfrom the prod stage too. Comparing against that other project's working implementation shows the real gap: it derives a genuineuprn+usrnpair from a postcode+house-number address lookup, while this scraper only ever accepts a raw UPRN with a hardcoded placeholderusrn. Matching that flow means changing this scraper's expected inputs (postcode+house number instead of UPRN alone) — a breaking change for existing users, not a same-shape fix — so it's reverted out of this release and left as a larger follow-up, with findings posted on Canterbury Council - 403 Error #2215.Not included
#2180 ("harden South Kesteven scraper and Home Assistant runtime") remains excluded. It's still the same 199-file, +13.5k/-3.6k change bundling the actual SKDC fix with an unrelated cross-council print-redaction sweep, a new test harness, and a rewrite of the release/CI pipeline. I asked the author in July whether they'd split it into reviewable pieces; there's been no response in two months, so it's left as-is for a maintainer to decide on separately.
Test plan
uk_bin_collectionunit suite green (no regressions)black --checkclean on all changed filescustom_components(HA redact fix) tests: green on Python 3.14 across every supported HA version in the compatibility matrix🤖 Generated with Claude Code
https://claude.ai/code/session_015MaCS29izthZp2dwtvLwf4
Summary by CodeRabbit