Skip to content

Chrome Updates Runbook

How to bump the emulated Chrome version across every tier — the wred sidecar (wire + behavioural profiles) and the wreq wheel (Path B). The failure mode of a stale fingerprint is a silent, site-wide block, so this is a recurring operational task, not a one-off.

Why it matters

TLS/HTTP2 emulation must track Chrome stable. Akamai and similar gates match a raw ClientHello against a known-browser baseline; a profile that describes a Chrome version the gate hasn't seen — or whose wire layer disagrees with the JS sensor — is rejected.

When to run

  • Chrome stable ships a new major version.
  • make chrome-watch (scheduled CI) flags a drift.

Toolkit repo (wre-toolkit-patched)

  1. Re-capture the behavioural profile (do not skip). The V8 sensor profile must agree with the wire profile. make chrome-capture N=<new> against a real Chrome captures the JS sensor signature; skipping it desyncs the two layers (the JS claims a different Chrome than the wire).

  2. Add the profile. make chrome-profile N=<new> BASE=<old> derives the new wire profile from the previous one.

  3. Verify. make chrome-verify N=<new> runs the hermetic fingerprint gate (no network, no Chrome).

  4. Tag + publish. Tag v<upstream>-chrome<new>.1; CI builds wred and publishes it to the GitLab generic package registry.

Scraper side

  1. Wheel (Path B). Bump the fork's wreq/btls-sys overlay, rebuild wreq-patched, and publish. Update pyproject.toml + uv.lock.

  2. Defaults. Update core/settings.py (wre_fingerprint, wre_profile, wreq_emulation) and the .env.example / docker-compose.yml defaults.

  3. Dockerfile. Bump WRE_TOOLKIT_VERSION and re-verify the sha256.

  4. Gates. The CI validate_wre / validate_wreq_emulation gates assert the configured names resolve in the built artifacts.

  5. Reference profiles. Re-run the live Best Buy smoke and the wreq smoke for booking_com / facebook_marketplace.

See docs/wre-integration-plan.md §8 for the full detail.