File detail
startup-performance.rq
reqlan rq/extension/host/startup-performance.rq
| Idea | Status | Tags | Summary | Katz |
|---|---|---|---|---|
| extension_startup_reliability | done | Reqlan startup must make the activity-bar shell and contributed commands available before optional indexing, parser construction, database initialization, or language-client startup can monopolize the extension host. The implementation contract is [first_paint_contract], [webview_claim_race], [deferred_startup_sequence], [lazy_runtime_dependencies], and [development_bundle_freshness]. Operational diagnosis follows [startup_diagnostics]. [activation.activation_sequence] [activitybar.loading_state] [indexer.nonblocking_index] [build.extension_bundle] | 0.046 | |
| observed_failure | Failure signature: - Reqlan contributes its activity-bar container and header buttons from `package.json`, but the Context view remains on VS Code's built-in spinner before the extension-owned " Loading Reqlan … " shell. - Contributed commands may be visible as menu items yet fail with `command 'reqlan.*' not found`. - The extension-host CPU profile can be mostly idle after the failure. This combination means static manifest contributions loaded but the extension module failed before `activate()` registered command handlers and the webview provider. | 0.040 | ||
| invalid_url_activation_failure | done | The concrete incident failed while requiring `out/extension/main.cjs`, before `activate()` ran: `TypeError: Invalid URL` in `embedPhysicsCoreSource`. Runtime `readFileSync(new URL(..., import.meta.url))` is unsafe when esbuild emits CommonJS for an ES2017 target: `import.meta.url` is unavailable / empty and source-relative assets do not exist beside the bundled entry. The HTML export used to embed physics via `html-export-assets.ts` `embedPhysicsCoreSource`. That writer is gone; export now inlines assets from ["../../../crates/reqlan-export/assets/app.js"]. Code that still needs a module directory or `createRequire` ( core engine loader and parse worker ) must not mention `import.meta` statically in a way that esbuild CJS empties: prefer CJS `__dirname` / `__filename` when those exist ( extension host bundle ), and `import.meta.url` on the Node ESM path ( CLI / MCP ). The host esbuild step defines `import.meta.url` as `import_meta_url` from this file's `__filename` so the CJS bundle stays valid and does not warn `empty-import-meta`. CLI / MCP keep the TypeScript `import.meta.url` emit. Do not eval `import.meta.url` — Node 24 treats that as a script eval and throws `Cannot use 'import.meta' outside a module`. ["../../../packages/analytical/src/native/load-native.ts"] ["../../../packages/language/src/reqlan-async-parser.ts"] ["../../../packages/extension/esbuild.mjs"] | 0.040 | |
| extension_host_process_model | One Node extension-host process for the development window is normal; multiple workers are not required for a healthy Reqlan activation. The language server is a separate child process launched only after extension activation reaches `LanguageClient.start()`. Therefore an idle extension host with no Reqlan language-server child is consistent with an earlier module-load / activation failure, not evidence that a worker is missing. | 0.040 | ||
| first_paint_contract | done | The platform spinner ends only after VS Code loads the host module, calls `activate`, the provider registers, and `resolveWebviewView` assigns HTML. `resolveWebviewView` is async: it binds the view, yields one turn so the overlay can be claimed, then assigns the lightweight HTML / Svelte shell ( retry once on invalid-state ). It does **not** `postMessage` in that method. The webview installs its host message listener, mounts, waits for its first animation frame, then posts the one-shot `ready` signal from a queued task. Host messages start only after that handshake. Index discovery / sync waits for the same signal so synchronous parser or database setup cannot race the first visible frame. Windows overlay restore can dispose and re-resolve the sidebar; the provider rebinds and waits for a new `ready`. [activation.first_paint_startup] [webview_claim_race] ["../../../packages/extension/webviews/activity-bar/App.svelte"] ["../../../packages/extension/webviews/activity-bar/state/app.svelte.ts"] ["../../../packages/extension/src/extension/startup-gate.ts"] ["../../../packages/extension/src/shared/safe-webview-post.ts"] | 0.058 | |
| webview_claim_race | done | Setting `webview.html` or calling `postMessage` before the workbench has claimed the overlay ( or after it has disposed it ) can fail with `Webview is in an invalid state` / `Webview is disposed`. This is intermittent and more common on Windows during extension init, when the activity-bar view is restored in the same tick as another webview ( first-run onboarding ). Contract: - Activity-bar host posts only after the webview's `ready` signal; `post` is a no-op until then and swallows disposed / invalid-state errors. - `resolveWebviewView` may run more than once: dispose prior view listeners, clear `webviewReady`, rebind, reassign HTML. - First-run onboarding waits for the activity-bar paint gate or 400 ms, whichever first, so it does not register a second webview service worker during sidebar claim. Palette `reqlan.showOnboarding` stays immediate. Index and language-client startup still use the existing paint / timeout fallbacks — a dead sidebar must not strand indexing. [first_paint_contract] [activation.onboarding_check] ["../../../packages/extension/src/activity_bar_module/activity-bar-webview-provider.ts"] ["../../../packages/extension/src/extension/main.ts"] ["../../../packages/extension/src/shared/safe-webview-post.ts"] | 0.091 | |
| deferred_startup_sequence | done | Required order: 1. Load the smallest practical host entry. 2. Synchronously register commands and the activity-bar provider; return from `activate`. 3. Yield one turn, assign the activity-bar shell, and wait for the post-first-frame `ready` handshake. Do not `postMessage` until `ready`. 4. Start index discovery / sync after `ready`; if the sidebar stays closed, start after a bounded three-second fallback so startup indexing and watchers are not lost. 5. Start the language client after `ready`, with a one-second fallback so language features work when the sidebar stays closed. 6. Open first-run onboarding after the same paint signal or 400 ms, so it does not race the sidebar iframe ( [webview_claim_race] ). 7. Report incremental index progress inside the already-painted sidebar. The ready signal and both startup paths are one-shot / idempotent. [activation.background_startup] | 0.046 | |
| lazy_runtime_dependencies | done | Base discovery must be cheap: - Constructing `WorkspaceIndex` does not construct Langium / Chevrotain services; index sync uses the core native engine ( rusqlite ). - The host-matching `reqlan_napi` `.node` is required at activate; there is no sql. js vendor bundle in the extension host. - Export / physics source is generated at build time rather than read via extension-runtime URLs. ["../../../packages/analytical/src/index-store/workspace-index.ts"] ["../../../packages/analytical/src/index-store/sqlite-store.ts"] ["../../../packages/analytical/src/index-store/index-diagnostics-store.ts"] ["../../../packages/extension/esbuild.mjs"] | 0.046 | |
| development_bundle_freshness | done | F5 executes `package.json.main` ( `out/extension/main.cjs` ), not TypeScript source. `out/`, generated webview media, and copied syntaxes are gitignored, so launching without a build can run missing or stale artifacts even when source already contains the fix. `.vscode/launch.json` therefore uses a deterministic pre-launch task that invokes the extension build orchestrator directly; root `pnpm run build:ext` delegates to the same script. The task content-fingerprints Langium and physics generation, each webview, packaging media, and extension-host / language-server output; `tsc -b` retains project-reference incrementality. Unchanged artifacts are verified and skipped before the development host opens. Watch mode remains useful during iteration, but concurrent watchers do not restart an already-running extension host or language-server child; stop and start F5 after host / server changes. ["../../../.vscode/launch.json"] ["../../../.vscode/tasks.json"] | 0.046 | |
| startup_diagnostics | Diagnosis order: 1. Read the development extension host's `remoteexthost.log`; find `ExtensionService#_doActivateExtension reqlan.reqlan-extension`. 2. Distinguish code-loading time, activate-call time, and activate-resolved time. 3. If activation failed, use the first Reqlan stack frame rather than inferring a CPU hang. 4. If manifest UI exists but every command is missing, investigate module load / activation before indexing or webview data. 5. If the extension-owned " Loading Reqlan … " shell appears, provider resolution succeeded; subsequent delays belong to webview bootstrap or index readiness. 6. Confirm `out/extension/main.cjs` is newer than changed source and includes a lazy vendor sql-asm import. CPU-idle profiles do not disprove activation failure: once `require()` throws, the host can remain healthy and mostly idle while Reqlan stays unregistered. | 0.046 | ||
| activation_events_learning | Modern VS Code derives activation for contributed views and commands. The incident log explicitly showed activation event `onView:reqlan.activityBar`, so the missing-command failure was not caused by a missing explicit `onView` entry. Activation-event changes should be justified from host logs and target-version behavior, not used to mask a module-load exception. | 0.040 | ||
| verification_contract | done | Startup changes are complete only when: - The production extension build succeeds and emits `out/extension/main.cjs`. - The main bundle does not embed a sql. js vendor; index open requires the core native engine. - Extension startup-gate, webview-claim, and analytical lazy-service tests pass. - Activity-bar shell paint is visually checked in a newly restarted F5 development host; activation failures are cached for the lifetime of a failed host session. - Requirement analysis resolves the updated startup graph. | 0.040 |
Related clusters
community
folder
status
status
tag
Local graph
Initialising graph…