Bugfix: Why doesn't the dock shell react to modulesLoaded$ after gen...

Documentation for Sessions

🐛 Bugfix: Why doesn't the dock shell react to modulesLoaded$ after gen...

Date: 2026-03-19
Time: 11:55:25 UTC
Session: gspace1-236.4
Agent: angular
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

Why doesn't the dock shell react to modulesLoaded$ after generation when it worked during initial load?

Task: S236: Fix platform generation pipeline — modulesLoaded$ only fires once

🎯 Decision Made

Chosen:

Remove take(1) from the modulesLoaded$ subscription in studio-dock-shell.component.ts so it reacts to EVERY emission, not just the first.

Options Considered:

  1. Remove take(1) (chosen — simple, correct, lets every modulesLoaded$ trigger rspack)
  2. Create a separate signal for post-generation loads (over-engineered, duplicates existing infrastructure)
  3. Use a BehaviorSubject instead of Subject for modulesLoaded$ (changes semantics for all consumers)

💭 Reasoning

Root cause: The dock shell subscribed to vfsSync.modulesLoaded$.pipe(filter(count > 0), take(1)). During initialization for a fresh universe, modulesLoaded$ fires with 0 (no modules on develop yet). The filter blocks it (count=0), but the take(1) is positioned AFTER filter — so take(1) doesn't consume it. However, in practice, the initial hydration calls refreshAllModulesFromRepo() which DOES emit modulesLoaded$ — if the GitLab repo has modules from a previous generation, take(1) consumes it. For subsequent generation-triggered refreshes, take(1) has already fired and the subscription is dead. Fix: Remove take(1) and keep filter(count > 0) + takeUntilDestroyed(). The isGeneratingModule() check prevents double-triggering during active generation.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation