build(deps): bump react-dom from 18.3.1 to 19.2.6#6
Closed
dependabot[bot] wants to merge 1 commit into
Closed
Conversation
Bumps [react-dom](https://github.com/facebook/react/tree/HEAD/packages/react-dom) from 18.3.1 to 19.2.6. - [Release notes](https://github.com/facebook/react/releases) - [Changelog](https://github.com/facebook/react/blob/main/CHANGELOG.md) - [Commits](https://github.com/facebook/react/commits/v19.2.6/packages/react-dom) --- updated-dependencies: - dependency-name: react-dom dependency-version: 19.2.6 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
Author
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
Author
|
Looks like react-dom is no longer a dependency, so this is no longer needed. |
DeveloperCodeBase
added a commit
that referenced
this pull request
May 28, 2026
Owner acked R4: Q0.a + Q1.a-Q5.a + dual-write forward-only. Locked + unaffected: Q0.a (nullable courseId widening, two-shape model), Q1.a (targetOfferingId), Q3.a (course-level + partial unique), Q4.a (full admin page), Q5.a (resultingEnrollmentId), dual-write forward-only (offeringId only, no cohort back-write — respects Sunset 2026-12-31).⚠️ Q2 implementation HOLD — Commit A paused (stop triggers #1/#2/#6): Schema + CODE discovery found the memo's Q2.a assumption «existing status values already match the enum» is incorrect: - Data: existing Enrollment.status is lowercase (active/completed/ dropped/withdrawn); Postgres enum is uppercase → direct cast fails - Code: existing enrollments.controller.ts (Phase-7, RBAC-gated) uses lowercase strings throughout — STATUSES const, @isin DTOs, self-enroll create, and the nuanced status-change RBAC (admin=any, instructor= completed-only, owner=withdrawn/dropped). Converting to Postgres enum rewrites all of it + needs a data migration. → Q2.a-as-stated (Postgres enum) is a §3 modification (existing-model change + data migration + existing-code rewrite), NOT the §4-additive «+60 LOC» the memo estimated. Trips #6 (existing-data migration ambiguity → STOP before proceeding) + #1 + #2. Recommended: Q2-via-service-layer — keep status as String (storage unchanged, zero migration, zero existing-code rewrite, zero prod-data risk); deliver the state-machine INTENT at the service layer in the new R4 transition endpoint (ALLOWED_TRANSITIONS + illegal-400, same as R2/R3.b LOGIC; the Postgres enum there was just greenfield storage). This is exactly what Phase B lesson #1 (schema discovery pre-code) + the D72 «ack ≠ ground truth on internals» lesson exist to catch — flagged before writing a migration that would fail on the owner's production data during their deploy step. Commit A paused pending owner Q2 confirm. Everything else ready. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
DeveloperCodeBase
added a commit
that referenced
this pull request
May 28, 2026
…gration + seed D74 logged (Q2 = service-layer) + R4 memo updated. Schema work per the locked Q0.a/Q1.a/Q5.a + Q2=service-layer decisions. Schema (apps/api/prisma/schema.prisma): - Enrollment.courseId String → String? (Q0.a nullable widening). Two-shape model: course-level (courseId set, legacy) + program-term admission (courseId null + offeringId set, R4 new). course relation becomes optional; onDelete stays Cascade (program-term rows unaffected — no course to cascade from). - Enrollment.status STAYS String (D74 Q2 = service-layer; NO Postgres enum). Comment documents the R4 admin transition endpoint enforces ALLOWED_TRANSITIONS at the service layer; values stay lowercase to match existing data + the existing Phase-7 RBAC controller. - Enrollment.resultingForApplication back-ref (Q5.a 1:0..1). - StudentApplication.targetOfferingId (Q1.a) + resultingEnrollmentId (Q5.a) nullable columns + relations (SetNull) + targetOffering / resultingEnrollment named relations. - CourseOffering.targetedByApplications reverse relation (Q1.a). Migration SQL (20260530000000_phase_b_r4_enrollment): - ALTER Enrollment.courseId DROP NOT NULL — pure constraint relax, existing rows keep courseId + stay valid (MIGRATION_POLICY §4 safe widening). Existing FK works against nullable column — no drop/ recreate. - Partial unique index "Enrollment_program_term_admission_key" on (tenantId, userId, offeringId) WHERE courseId IS NULL AND deletedAt IS NULL — enforces one active program-term admission per offering; soft-delete lets re-enroll (Q3.a). Authored as raw SQL because Prisma DSL can't express partial uniques (NOT in schema.prisma; lives only in this migration). - StudentApplication.targetOfferingId + resultingEnrollmentId columns + FKs (SetNull) + unique on resultingEnrollmentId + index on targetOfferingId. - status column UNTOUCHED — no enum, no data migration, zero prod-data risk (D74). Seed (apps/api/src/prisma/seed.ts): - Sample program-term Enrollment (offeringId set, courseId null) for student1 into the seed offering — demonstrates the Q0.a shape the R4 ENROLLED side effect will create. Idempotent (deterministic id). Validated: - `prisma validate` clean - `prisma generate` clean (courseId now optional in client types) - `tsc --noEmit` clean Migration safety note (per owner Commit A directive + stop trigger #6): the courseId widening is a pure NOT NULL → NULL relax — existing rows are untouched by definition (no value change, only constraint relax). No ambiguity on existing data. The status column is deliberately NOT migrated (D74), eliminating the enum-cast-on-existing-data risk that the R2 migration-failure pattern warned about. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
DeveloperCodeBase
added a commit
that referenced
this pull request
May 30, 2026
Owner locked the five Candidate-C Q-decisions after reviewing the scoped memo (91bdcdb), with a mandatory security-hardening rider on Q2.b (token-based anon tracking): unguessable >=128-bit crypto token, token shown on confirmation page, rate-limited /track, token never logged, and a non-sensitive /track GET subset (PII mask). Records the locked answers, the 5th Phase B discovery catch (R3.b /me + /withdraw can't serve anon applicants — no User until ENROLLED), the Q2.b resolution, the Q1.a PUBLIC-route correction, the active D61 stop-trigger set for R6, the R5 Phase-2 deploy/close plan, and the Phase B closure note. Next: Commit A (trackingToken migration + schema). One token-entropy fork (stop-trigger #6) goes to the owner before the migration lands. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
DeveloperCodeBase
added a commit
that referenced
this pull request
May 30, 2026
Stop-trigger #6 fork resolved by owner («Option 1, برو»). App-level mint crypto.randomBytes(24) base64url = 192-bit in submitPublic (B), NOT a DB @default — because no Prisma/PG default reaches the >=128-bit floor (uuid v4 = 122-bit under floor; cuid not crypto-random). Reuses the repo generateSecurePassword pattern. Schema: trackingToken String? @unique (nullable, public submissions only). Collision: @unique + regenerate-on-P2002 (<=3). PII-mask: nationalId masked, internal ids dropped. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
DeveloperCodeBase
added a commit
that referenced
this pull request
May 30, 2026
Phase B R6 (Candidate C) Commit A. Adds the public anon-applicant tracking token column to both application models, MIGRATION_POLICY §4 additive (nullable, unique, no backfill, no downtime): - StudentApplication.trackingToken String? @unique - InstructorApplication.trackingToken String? @unique Nullable by design: only public submissions mint a token (Commit B); pre-existing + admin-created rows stay NULL and are tracked via /admin/applications. Postgres treats NULL as DISTINCT in a unique index, so many NULL rows coexist; the unique constraint binds only minted tokens. No DB DEFAULT: per D80 stop-trigger #6, no Prisma/Postgres default reaches the >=128-bit hardening floor (uuid v4 = 122-bit; cuid is not crypto-random). The token is minted app-level in Commit B via crypto.randomBytes(24).toString("base64url") (192-bit), reusing the generateSecurePassword pattern. Hand-authored migration SQL (index names follow Prisma's <Model>_<field>_key convention so migrate treats them as managed). prisma validate + generate + tsc --noEmit clean. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
DeveloperCodeBase
added a commit
that referenced
this pull request
May 31, 2026
…0/D81) Phase B R6 (Candidate C) Commit B — the backend slice that makes anon applicant status-tracking + withdraw possible (R3.b's /me + /withdraw need a JWT + app.userId, which anon applicants lack until ENROLLED). Tracking token (D80, stop-trigger #6 = Option 1): - applications.types.ts: generateTrackingToken() = crypto.randomBytes(24) .toString("base64url") = 192-bit, app-level (no DB default reaches the >=128-bit floor). Plus isTrackingTokenCollision (P2002 regen signal), PUBLIC_TRACK_ACTOR sentinel, canApplicantWithdraw, deriveApplicationReference (APP-XXXXXX, not the raw cuid), maskEmail/maskPhone, and the PublicApplicationView shape + buildPublicApplicationView mapper. - both services: mint a token in submitPublic (createWithTrackingToken, regenerate-on-P2002 <=3); backfill on idempotent re-submit so a re-submit always yields a working /track link; getByToken (PII-masked: nationalId omitted, raw ids dropped, email/phone masked; soft-deleted / empty / unknown token -> 404, no enumeration leak; token never logged); withdrawByToken (reuses the canonical transition path so the state machine validates — terminal -> 400; records the public-track sentinel actor since the anon applicant has no User). - both controllers: @public @Throttle GET /track (30/IP/hr) + @public @AuditSkip @Throttle POST /track/withdraw (5/IP/hr), declared before the :id routes so the literals win over the :id param. Green-all-4 (D81, Option A): added @AuditSkip() + AuditSkip import to the 2 new public mutations AND the 2 pre-existing R3.b submit handlers (which carried the @AuditSkip comment but never the decorator). audit-on-mutation lint now PASSES (27 files, 0 violations) — fulfils R3.b's documented intent and unblocks the D29 e2e run. e2e spec (applications-r6-tracking.spec.ts): token mint, masked view, PII-mask (no nationalId / ids), forged+empty -> 404, withdraw -> WITHDRAWN + sentinel actor, decided(REJECTED) -> 400, idempotent same-token, instructor variant. tsc --noEmit + prisma validate/generate clean. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
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.
Bumps react-dom from 18.3.1 to 19.2.6.
Release notes
Sourced from react-dom's releases.
... (truncated)
Changelog
Sourced from react-dom's changelog.
... (truncated)
Commits
eaf3e95Version 19.2.623f4f9f19.2.590ab3f8Version 19.2.4612e371Version 19.2.3b910fc1Version 19.2.2053df4eVersion 19.2.18618113Bump scheduler version (#34671)1bd1f01Ship partial-prerendering APIs to Canary (#34633)2f0649a[Fizz] Removenonceoption from resume-and-prerender APIs (#34664)5667a41Bump next prerelease version numbers (#34639)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 rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill 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 versionwill 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 dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)