Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Parent runtime republished with react 19.2.9 shared deps breaks rc.16-pinned children (SSR composition fails)

Chiusa
#546 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Una pull request collegata è già stata integrata.

  • #552 di @elliotBraem — integrata

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
react, typescript
Ambito
backend, devops

Direzione di ricerca

Start by tracing how the parent config and host bundle expose platform versions, then follow the ADR 0034 compatibility check used during child boot. Compare that check with the shared React version negotiation described in the report. Done means a pinned child detects this incompatibility before SSR composition, or parent publication is gated so the incompatible versions cannot be deployed together.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

The parent runtime published at bos://dev.everything.near/everything.dev was re-published with UI bundles built against react 19.2.9, while children still pinned to platform 2.0.0-rc.16 build their UI against react 19.2.4 (both the npm package [email protected] and its scaffold catalog). The react shared singleton negotiation then fails during SSR composition, breaking boot for every rc.16-pinned child against the live parent.

Failure mode

Host SSR composition boot fails and health stays degraded:

[host] [Server] Boot SSR composition FAILED — health stays degraded: UnknownError:
An error occurred in Effect.tryPromise(cause: Error: [ Federation Runtime ]:
Version 19.2.4 from ui of shared singleton module react does not satisfy the
requirement of undefined which needs 19.2.9))
Why the platform pin didn't catch it (ADR 0034)

The published parent config at bos://dev.everything.near/everything.dev carries no platform field, and the parent's host bundle mf-manifest.json still reports buildInfo.buildVersion: "2.0.0-rc.4" — so a child's platform: "2.0.0-rc.16" pin in bos.app.ts cannot detect that the parent's shared dependencies have drifted underneath it. The child booted "successfully" per the pin check and then failed at federation negotiation.

Verified state at time of report:

  • Parent UI bundle (versions/3676ff3f0aca1868.json, gitSha 4fdddd2): shared declares react/react-dom version: 19.2.9, requiredVersion: 19.2.9, singleton: true
  • [email protected] package: react/react-dom 19.2.4
  • [email protected]/rc.18 packages: react/react-dom 19.2.9
  • rc.16-pinned children are therefore incompatible with the currently-published parent bundles
Reproduction
  1. Child repo pinned at [email protected], platform: "2.0.0-rc.16" in bos.app.ts
  2. Deploy on ghcr.io/nearbuilders/everything-dev:v2.0.0-rc.16
  3. Host resolves the live parent config (react 19.2.9 UI bundles) and fails SSR composition with the federation version error above
Expected behavior

Either (or both):

  1. Platform compat guard: published configs and/or host bundles should advertise the platform version they were built with, so the ADR 0034 pin check fails loudly with a clear "parent is X, you pinned Y" message instead of a cryptic federation error at SSR boot.
  2. Coordinated parent republish: when the live parent's shared deps move (react 19.2.4 → 19.2.9), the corresponding npm rc package should land first and the parent republish should be gated on it, so a pinned child never silently breaks against a drifted parent.
Workaround for affected children

Upgrade to [email protected] (catalog react 19.2.9), update the platform pin in bos.app.ts, and redeploy on ghcr.io/nearbuilders/everything-dev:v2.0.0-rc.18. Verified working in a child repo (feedback.nearbuilders.org / nearbuilding.near).

Lingua principale
TypeScript
Stelle
5
Fork
3
Merge medio
10h 38m
PR unite (30g)
119

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di NEARBuilders/everything-dev

Tutte le issue di NEARBuilders/everything-dev

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.