Skip to content

Harden DBR umbrella: bound probe cost and pin connect to the major line - #27

Open
rugpanov wants to merge 3 commits into
mainfrom
fix/dbr-umbrella-hardening
Open

Harden DBR umbrella: bound probe cost and pin connect to the major line#27
rugpanov wants to merge 3 commits into
mainfrom
fix/dbr-umbrella-hardening

Conversation

@rugpanov

@rugpanov rugpanov commented Aug 28, 2026

Copy link
Copy Markdown
Collaborator

Follow-up hardening for the DBR 18+ umbrella scheme merged in #26. Non-blocking review findings from that PR, addressed in one pass.

Changes

  • Bound the probe for a bare major with no point-release pages (DBR 19 today). Gating the trailing-404 break on "a page has been seen" let such a line scan the full 0..max_minor range — ~52 HTTP requests per line. A separate max_leading_misses cap (5) ends the probe after a short run of leading 404s, kept above the 2-consecutive slack that bridges a removed early page. EoS pages don't count toward it (they reset the counter).
  • Pin the umbrella's databricks-connect to the whole major line18.x~=18.0 instead of the latest point release's ~=18.2.0 — matching the serverless whole-major convention (dbconnect_pin). Point-release folders keep their exact-minor pin. Regenerates the 18.x / 19.x umbrella artifacts (~=18.0, ~=19.0).
  • Simplify live_page to return just the classification; the page body was discarded at every call site.

Why

A cluster addressing a line by its bare major should resolve the newest databricks-connect in the major, and pick up a new point release without waiting on a regen. Verified with uv: 18.x now resolves to 18.3.4 (was capped at 18.2.x) and 19.x to 19.1 (the old ~=19.0.0 pin was already too tight to reach it). The probe cap keeps the weekly job from spending ~40s per bare major discovering pages that don't exist.

Tests

43 → 47 unit tests: a probe-count bound for the no-point-release line, both leading-cap boundary cases (a live release within the slack is found; one past the cap is not), and an end-to-end sync_dbr assertion for the DBR-19 umbrella-only path (where dbr_meta defaults the minor). All green; artifacts regenerated by sync.py.

rugpanov and others added 3 commits August 28, 2026 19:46
…he major line

Follow-up hardening for the DBR 18+ umbrella scheme:

- Cap the point-release probe for a bare major with no point-release pages
  (DBR 19 today). Gating the trailing-404 break on "a page was seen" let such
  a line scan the full 0..max_minor range (~52 requests). A separate
  max_leading_misses cap (5) ends the probe after a short run of leading 404s,
  keeping it above the 2-consecutive slack that bridges a removed early page.

- Pin the bare-major umbrella's databricks-connect to the whole major line
  (18.x -> ~=18.0) instead of the latest point release's minor (~=18.2.0),
  matching the serverless whole-major convention. A cluster addressing the
  line by its bare major now resolves the newest connect in the major, and a
  new point release is covered without a regen. Point-release folders keep
  their exact-minor pin. Regenerates the 18.x / 19.x umbrella artifacts.

- Simplify live_page to return just the classification (the page body was
  discarded at every call site) and note the transient no-live no-op window.

43 -> 46 unit tests: probe-count bound, leading-cap boundary, and an
end-to-end DBR-19 umbrella-only assertion.

Co-authored-by: Isaac <no-reply@databricks.com>
…he value

Review follow-up. No behavior change:
- Add a boundary test locking max_leading_misses=5 — a live release past a full
  run of leading 404s (18.0..18.4 deleted, 18.5 live) is not discovered, so a
  future change to the cap is a deliberate, visible edit.
- Expand the comment: only genuine 404s count toward the cap (an EoS page is a
  hit that resets the counter, and upstream marks pages '(EoS)' rather than
  deleting them), and explain why 5.

Co-authored-by: Isaac <no-reply@databricks.com>
Point releases are numbered contiguously from .0, so five leading 404s mean
none were published (the empty case), not a gap. Comment + test docstring no
longer conflate 'never existed' with 'deleted'. No behavior change.

Co-authored-by: Isaac <no-reply@databricks.com>
@rugpanov
rugpanov marked this pull request as ready for review August 28, 2026 18:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant