Update pydantic requirement from >=2.0 to >=2.13.4 - #5
Conversation
0b35ecb to
7a73f1c
Compare
The certification caught a satellite serving its ADMIN CONTROL BOARD to a browser that had already signed out on the primary. This is that fix. 1.0.3 revoked the server session on a signed-in -> signed-out TRANSITION, which requires the tab to have observed the signed-in state first. A browser that signs out on 2plot.ai and then simply navigates here never had one: ClerkJS resolves signed-out immediately, while the server still holds __dca_identity and has already rendered the page — gated content included — off it. 1.0.4 reconciles on load: ClerkJS signed-out while the server stamped `clerk-signed-in` on <html> means POST /api/auth/signout, then reload. That class is the only signal available, because __dca_identity is HttpOnly and the page cannot read it. Verified present in this app's rendered index. Also fixed upstream: POST /api/auth/session and /api/auth/signout returned 422 on EVERY FastAPI deployment for as long as they had existed — handlers whose `request` parameter was unannotated, which FastAPI resolves as a required query field. Inert here (production is Flask under Docker) and pinned anyway: lib/backend.py makes a backend switch one env var away, and the failure mode is silent, because the injected script never inspects the result. Sign-out would simply stop revoking. THE SHIM STAYS ONE MORE RELEASE, against its own docstring. lib/auth.py's _install_signout_delegation was written expecting to retire at 1.0.4. It is not retiring, because 1.0.4's acceptance test IS sign-out behaviour, and pulling the local handler in the same change makes a failure ambiguous between "1.0.4 does not work" and "the shim was load-bearing". They cannot collide — the shim is a click handler owning the capture phase, the new reconciliation runs once on load — and the POST is idempotent. Retire it in the pass after the test passes. The docstring now says this instead. ARTIFACT VERIFIED BY HASH, not by filename or mtime. A stale first build of 1.0.4 exists (22117b20...) and is rejected; the vendored blob is 7a7c333af8da4739e944e3260f332a7f1a70dc3c4fd93ae9f10a197f14cf701a, checked after the copy and byte-identical to the authoring repo's dist. The "authoring main holds the broken build" caveat from the 1.0.3 bump is now historical — PR #5 (62071e4) merged 2026-08-21 and main carries both the import fix and 1.0.4 — but the hash rule stays, because both releases were built-then-committed seconds apart, which reads exactly like shipping a pre-fix build and is not. session_lifetime_days stays 7, still an explicit decision. 1.0.4 narrows what that window costs: a ghost is now revoked on the next page load rather than persisting for the cookie's life. Verified: 186 passed (flask) / 185 + 1 skip (fastapi), smoke 72/72, flake8 clean, and a real satellite-mode boot on 1.0.4 — reconciliation script in the page, both shims intact, satelliteSignInRedirect populated, POST /api/auth/signout 200. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two halves of the same certification, in one commit because they deploy together. === dash-clerk-auth 1.0.4: the ghost that served the control board === The certification caught a satellite serving its ADMIN CONTROL BOARD to a browser that had already signed out on the primary. 1.0.3 revoked the server session on a signed-in -> signed-out TRANSITION, which requires the tab to have observed the signed-in state first. A browser that signs out on 2plot.ai and then simply navigates here never had one: ClerkJS resolves signed-out immediately, while the server still holds __dca_identity and has already rendered the page — gated content included — off it. 1.0.4 reconciles on load: ClerkJS signed-out while the server stamped `clerk-signed-in` on <html> means POST /api/auth/signout, then reload. That class is the only signal available, because __dca_identity is HttpOnly and the page cannot read it. Verified present in this app's rendered index. Also fixed upstream: POST /api/auth/session and /api/auth/signout returned 422 on EVERY FastAPI deployment for as long as they had existed — handlers whose `request` parameter was unannotated, which FastAPI resolves as a required query field. Inert here (production is Flask under Docker) and pinned anyway: lib/backend.py makes a backend switch one env var away, and the failure mode is silent, because the injected script never inspects the result. Sign-out would simply stop revoking. THE SHIM STAYS ONE MORE RELEASE, against its own docstring. _install_signout_delegation was written expecting to retire at 1.0.4. It is not, because 1.0.4's acceptance test IS sign-out behaviour, and pulling the local handler in the same change makes a failure ambiguous between "1.0.4 does not work" and "the shim was load-bearing". They cannot collide — the shim is a click handler owning the capture phase, the reconciliation runs once on load — and the POST is idempotent. ARTIFACT VERIFIED BY HASH, not filename or mtime. A stale first build of 1.0.4 exists (22117b20...) and is rejected; the vendored blob is 7a7c333af8da4739e944e3260f332a7f1a70dc3c4fd93ae9f10a197f14cf701a, checked after the copy and byte-identical to the authoring repo's dist. The "authoring main holds the broken build" caveat from the 1.0.3 bump is now historical (PR #5, 62071e4, merged 2026-08-21), but the hash rule stays: both releases were built-then-committed seconds apart, which reads exactly like shipping a pre-fix build and is not. === The control-board store says when it is about to lose your toggles === The stage-3 env diff found PAGE_VISIBILITY_FILE declared in render.yaml and ABSENT from the live service, because Render applies Blueprint envVars on a sync and not on an autoDeploy. Unset, _STORE_PATH falls back to a file in the app directory, which a Docker deploy replaces wholesale — every control-board toggle silently resetting on every redeploy. Nothing said so. Now a boot line does, and it checks BOTH halves: the variable being set, and /var/data actually being a mounted disk. The second matters because an app can mkdir /var/data on the container filesystem and behave identically right up until the next deploy wipes it, which is indistinguishable from the unset case without the mount check. The absence of these lines in a deploy log is the acceptance check that the variable and the disk both landed. Also: the mobile drawer is the boilerplate's — full-height, docked beneath the fixed header (HEADER_HEIGHT, one number shared with appshell), overlay starting below it so the hamburger stays tappable and toggles closed, and a sticky search field, because the header's Select is hidden on phones and the drawer otherwise cannot jump to a page. Verified: 188 passed (flask) / 187 + 1 skip (fastapi), smoke 72/72, flake8 clean, a real satellite-mode boot on 1.0.4 with the reconciliation script in the page and both shims intact, and the new warning exercised both ways. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
7a73f1c to
9ce4984
Compare
Updates the requirements on [pydantic](https://github.com/pydantic/pydantic) to permit the latest version. - [Release notes](https://github.com/pydantic/pydantic/releases) - [Changelog](https://github.com/pydantic/pydantic/blob/main/HISTORY.md) - [Commits](pydantic/pydantic@v2.0...v2.13.4) --- updated-dependencies: - dependency-name: pydantic dependency-version: 2.13.4 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
9ce4984 to
c7e62b8
Compare
|
Closing per the network's dependabot policy: this is a floor-raise on a range requirement. Floors encode minimum-compatibility knowledge (the gunicorn floor IS the CVE fact); the resolver already installs the latest release under them, and raising the floor erases that meaning while adding none. Security updates are unaffected — they arrive through GitHub's separate security-update channel. Floor moves happen deliberately via the template's sync specs, every encoding at once. — 2plot-network ops seat (dependabot-triage) |
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
Updates the requirements on pydantic to permit the latest version.
Release notes
Sourced from pydantic's releases.
Changelog
Sourced from pydantic's changelog.
... (truncated)
Commits
cf67d4bFix lintingf0d8a21Prepare release v2.13.45e3fe1dCheck for pydantic tag pattern in CI7f9edccDocument tagging conventionsb46a0c9Adaptpydantic-corelinker flags on macOS50629c8Update to PyPy 7.3.228522ebbPreserveRootModelcore metadataa37f3afAdaptMISSINGsentinel test to work with unreleasedtyping_extensionsver...909259aRemove Logfire example in documentation2c4174cBump libc from 0.2.155 to 0.2.185