Repository navigation
fix: resolve view-bound admin singletons under @webiny/di 2.0 - #5979
Conversation
… view Every content entries page failed with "No registration found for CmsModelContext". The trash bin's gateway adapters read CmsModelContext, which only the per-view child container registers, but CmsTrashBinFeature registered them as singletons on the root. @webiny/di 2.0 (#5969) builds a singleton from the container that holds its registration, so the root could no longer reach CmsModelContext. Under 1.x the first view to open the trash bin built the adapters against its own model, and every later view shared that instance. The trash bin now registers on the content entries view's child container, next to CmsModelContext, as Website Builder does with its pages trash bin. Each model's view gets its own. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
🚓 Slop Cop ✅ Nothing worth flagging. The diff looks consistent with the PR's stated intent and the code-style rules. Small, coherent fix matching its stated intent; no integrity or style issues found. Automated, non-blocking heads-up from an LLM. It can be wrong — use your judgment. Regenerates on every push. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to
|
Two more root singletons depend on presenters that only a view's child container registers, so under @webiny/di 2.0 they fail the same way the CMS trash bin did: - CmsCompareEntryRevisionsPresenter (ai-powerups) reads RevisionsListPresenter from the content entries view. Opening any CMS entry failed with "No registration found for RevisionsListPresenter". - ReenrichWithAiPresenter (app-file-manager) reads FileDetailsPresenter from the File Manager view, so opening a file's details would fail. Both are now registered with inContainerScope(). A container-scoped instance is built from the container that resolves it, which is the view's child, and is cached there, so components in one view still share it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@webiny/di2.0 (#5969) builds a singleton from the container that holds its registration, not from the container that resolves it. Three admin singletons were registered on the root container but depend on something that only a view's child container registers, so they now fail to resolve:CmsTrashBinFeature(trash bin presenter and gateway adapters), viaContentEntryFeatureCmsModelContext, fromContentEntriesViewCmsCompareEntryRevisionsPresenter(ai-powerups)RevisionsListPresenter, fromContentEntriesViewReenrichWithAiPresenter(app-file-manager)FileDetailsPresenter, fromFileManagerViewUnder
di1.x all three worked by accident. The first view to resolve them built them against its own child, the root cached the result, and every later view shared it. The CMS trash bin, for example, kept the model of whichever list opened first.Fix
CmsTrashBinFeatureregisters on the content entries view's child container, next toCmsModelContext, andContentEntryFeatureno longer registers it. Website Builder already does the same with its pages trash bin (PagesList.tsx). Nothing outside the trash bin uses the three use-case features it registers.inContainerScope()instead ofinSingletonScope(). A container-scoped instance is built from the container that resolves it, here the view's child, and cached there. The compare-revisions menu item and its overlays still share one instance per view.How the cases were found
I traced every
createChildContainer()site in the admin packages and checked each singleton reachable from the root for a dependency, direct or transitive, that only a child registers. These three are all the cases. Theapp-acofolder features, the record-locking, workflow and scheduler decorators, and the collaboration, notifications and webhooks presenters were checked and are fine. One known behaviour change remains that doesn't crash. Root singletons that readLocalStoragenow get the root instance rather than the tenant-prefixed one the tenancy provider registers. That affects the GraphQL playground's tabs and query history, which are now shared across tenants. It's left for a separate change.Testing
yybbuilds. Tests pass:app-headless-cmscontent entry presenters (8 files, 58 tests),app-file-manager(13 files, 124 tests),ai-powerups(11 files, 89 tests).StreamingPlaceholder, is unrelated.Workspace: wby-next2 · 🧹 MERGE 6.5.0 => NEXT
🤖 Generated with Claude Code
Summary by CodeRabbit