fixed intellisense and autocomplete for connect pipeline editor and fixed CSS cascade issue with popover not showing

[eblairmckee]

Fix Monaco YAML Editor Intellisense & Popovers

Problem

The Monaco YAML editor has two distinct failures:

1. Invisible hover popovers (affects ALL editors, including old PipelinesYamlEditor) — hover tooltips show a border but content is invisible. Autocomplete popovers work fine.
2. No schema-driven intellisense (new YamlEditor only) — the JSON schema passed to configureMonacoYaml produces no completions or validation in the pipeline page.

The intellisense issue is specific to the new YamlEditor refactor. The hover popover issue is global and caused by a Tailwind v4 CSS class name collision.

Assumptions

ASSUMPTIONS:
1. The old PipelinesYamlEditor (src/components/misc/pipelines-yaml-editor.tsx) still works correctly with completions + visible popovers
2. The backend schema endpoint returns valid JSON schema (since it worked before)
3. The YAML worker is loading (no console errors about worker failures)
4. Monaco is using the bundled instance (via loader.config({ monaco }) in config.ts)
→ Correct me now or I proceed with these.

Success criteria: When editing YAML in the pipeline page, (1) hover tooltips and autocomplete suggestions are visible with correct styling, and (2) typing a top-level key triggers schema-driven completions showing valid Redpanda Connect component names.

Constraints & Non-Goals

Constraints:

• Tailwind v4, Rsbuild (rspack), React 18.3
• Must use the new YamlEditor component (not revert to old one)
• monaco-editor ^0.54.0, monaco-yaml ^5.4.0

Non-goals:

• Redesigning the editor component architecture
• Adding new editor features beyond fixing what's broken
• Fixing the old PipelinesYamlEditor

Root Cause Analysis

Root Cause 1: Missing path prop (kills intellisense)

The old editor sets path={'new-connector.yaml'}. The new editor sets no path. Monaco-yaml matches schemas to editor models via fileMatch: ['**/*.yaml']. Without a .yaml path, the model gets an auto-generated URI like inmemory://model/1 that doesn't match the glob, so the schema is never applied.

Fix: Add path="pipeline.yaml" (or any *.yaml name) to the <Editor> component in yaml-editor.tsx.

Root Cause 2: onMount vs beforeMount timing (may cause race)

The old editor calls configureMonacoYaml in beforeMount. The new editor calls it in onMount. When called in onMount, the editor model already exists. Monaco-yaml applies schemas to models at configuration time — if the model exists before the schema is configured, it may not get the schema applied.

Fix: Switch from onMount to beforeMount for the initial configureMonacoYaml call, matching the working old editor pattern.

Root Cause 3: overflow-hidden on parent container (clips widgets)

yaml-editor-card.tsx:88-89 wraps the editor in a div with overflow-hidden. Monaco's hover tooltips and autocomplete widgets are absolutely positioned and extend beyond the editor bounds. overflow-hidden clips them, making them invisible.

Fix: Add fixedOverflowWidgets: true to the editor's default options. This tells Monaco to render widgets using position: fixed (or into an overflow widget container), bypassing the parent's overflow-hidden.

Root Cause 4: tw-animate-css .fade-in class collision with Monaco [CONFIDENCE: HIGH — confirmed via DevTools]

tw-animate-css (imported in globals.css) defines .fade-in { opacity: 0; animation: .3s forwards fadeIn; }. Monaco internally uses a fade-in class on .monaco-hover for its own hover animation (.monaco-hover.fade-in { animation: .1s linear fadein; }). Monaco's rule doesn't set opacity, so the tw-animate-css rule's opacity: 0 applies and is never overridden, making hover content permanently invisible.

This explains why:

• The hover border is visible (outer monaco-resizable-hover container doesn't use .fade-in)
• The hover content is invisible (opacity: 0 from tw-animate-css)
• Autocomplete works fine (the suggest-widget does NOT use a fade-in class)
• This affects ALL Monaco editors, including the old PipelinesYamlEditor

Fix: Add a CSS override in globals.css after the tw-animate-css import:

.monaco-hover.fade-in {
  opacity: 1;
}

Root Cause 5: Double configureMonacoYaml call on mount

In yaml-editor.tsx, configureMonacoYaml is called in onMount (line 132) AND the useEffect on monacoYamlOptions (line 115) fires immediately after because monacoRef.current was just set. This means it's disposed and re-created back-to-back. The monaco-yaml docs state: "There may only be one configured instance of monaco-yaml at a time." The double-call with dispose in between may cause a race condition where the schema isn't applied to the already-created model.

Fix: Only call configureMonacoYaml once — in beforeMount for initial setup. The useEffect should only handle subsequent schema changes (guard with a "has mounted" check).

Root Cause 6: window.MonacoEnvironment set asynchronously [CONFIDENCE: MEDIUM]

In config.ts:398-414, window.MonacoEnvironment (which provides getWorkerUrl) is set inside loader.init().then(...). Even though loader.config({ monaco }) makes loader.init() resolve immediately, the .then() callback executes as a microtask — meaning MonacoEnvironment may not be set when the editor first tries to spawn the YAML worker. If the worker doesn't load, no completions, hover, or validation will work.

Fix: Move window.MonacoEnvironment = { getWorkerUrl(...) {...} } before the loader.init() call so it's set synchronously.

Proposed Fix

No architecture changes needed. The fixes are targeted:

#	File	Change	Addresses	Status
1	globals.css	CSS override: .monaco-hover.fade-in { opacity: 1; } to fix tw-animate-css collision	Invisible hover popovers (all editors)	✅ Done
2	yaml-editor.tsx	Add path="pipeline.yaml" to <Editor>	No intellisense (new editor)	✅ Done
3	yaml-editor.tsx	Move configureMonacoYaml from onMount to beforeMount	Schema not applied (new editor)	✅ Done
4	yaml-editor.tsx	Add fixedOverflowWidgets: true to defaultOptions	Widget clipping from overflow-hidden	✅ Done
5	yaml-editor.tsx	Use update() API instead of dispose+recreate; skip initial useEffect with hasInitializedRef	Race condition + schema request error	✅ Done (revised)
6	config.ts	Move window.MonacoEnvironment before loader.init()	Worker may not load	✅ Done
7	yaml-editor.tsx	Always provide inline schema (even empty { type: 'object' }) to prevent URI fetch	Schema URI fetch fallback	✅ Done
8	yaml-editor.tsx	Change schema URI from https://redpanda-connect-schema.json to https://redpanda.com/connect-schema.json	URI normalization mismatch	✅ Done

Root Cause 7: URI normalization mismatch in json-language-service (THE ACTUAL BUG)

Discovered after initial fixes. Error: Unable to load schema from 'https://redpanda-connect-schema.json'. No schema request service available YAML(768)

Root cause: vscode-uri normalizes https://redpanda-connect-schema.json → https://redpanda-connect-schema.json/ (adds trailing / because the parsed path component becomes /). The json-language-service has a bug in registerExternalSchema (yaml.worker.js:1421): it stores the schema handle under the normalized URI but stores the file pattern association with the original URI. When validation looks up the schema, it retrieves the original URI from the file pattern, passes it to getOrAddSchemaHandle, which looks up schemasById[originalUri] — but the entry is under schemasById[normalizedUri]. The lookup fails, creating a new empty SchemaHandle that triggers loadSchema() → no request service → error.

Confirmed via vscode-uri:

URI.parse('https://redpanda-connect-schema.json').toString()
→ 'https://redpanda-connect-schema.json/'  // TRAILING SLASH ADDED — doesn't match original

URI.parse('https://redpanda.com/connect-schema.json').toString()
→ 'https://redpanda.com/connect-schema.json'  // matches original ✓

URI.parse('https://github.com/redpanda-data/...').toString()
→ 'https://github.com/redpanda-data/...'  // matches original ✓ (old editor)

The fix: Change the schema URI to one with a proper path component that normalizes to itself: https://redpanda.com/connect-schema.json.

Root Cause 8: Dispose+recreate lifecycle (secondary issue, also fixed)

The old code disposed configureMonacoYaml and recreated it on schema changes. The configureMonacoYaml API provides an update() method specifically for this purpose — it properly restarts the YAML worker with new schema data without tearing down and re-registering all language providers.

Additionally, always provide an inline schema object (even the empty { type: 'object' } fallback) so the SchemaHandle always has unresolvedSchema set.

Tradeoffs

• fixedOverflowWidgets: true — Widgets render outside the editor container, which is correct for our layout. Potential downside: if the editor is inside a modal/dialog, widgets may appear outside the dialog. This is already handled by the expanded-yaml-dialog using its own container.
• beforeMount instead of onMount — We lose access to the editor instance at configuration time, but configureMonacoYaml only needs the monaco namespace, not the editor instance. The useEffect for schema updates still works via yamlRef.current.update().
• Static path prop — All YamlEditor instances will share the same model URI path. If multiple editors exist simultaneously, they'd share the schema config. This is fine since configureMonacoYaml is global (one instance at a time per monaco-yaml docs).
• update() vs dispose+recreate — update() is the intended API for schema changes. It avoids re-registering all language providers and avoids the timing gap that caused the schema request error. Downside: none — this is strictly better.

Reviewer Critique

Dimension	Assessment
Simplicity	Good — 6 targeted fixes, no new abstractions
Failure modes	Low risk — each fix is independently verifiable
Scope creep	Clean — no unrelated changes
Confidence gaps	Root Cause 4 (Tailwind .hidden collision) is HIGH confidence — confirmed via DOM inspection showing .monaco-hover.hidden with content present but invisible. Root Cause 6 (MonacoEnvironment race) is MEDIUM — needs verification
Alternatives rejected	Could use overflowWidgetsDomNode instead of fixedOverflowWidgets, but that requires creating a DOM ref — more complexity for same outcome. Could use Tailwind prefix to avoid class collisions globally, but that's a massive migration

Implementation Steps

Step 1: Fix tw-animate-css .fade-in collision (highest impact — fixes all editors) ✅

Added CSS override to globals.css after the tw-animate-css import:

.monaco-hover.fade-in {
  opacity: 1;
}

Step 2: Fix path prop ✅

Added path="pipeline.yaml" to <Editor> in yaml-editor.tsx.

Step 3: Fix timing ✅

Moved configureMonacoYaml from onMount to beforeMount.

Step 4: Fix widget clipping ✅

Added fixedOverflowWidgets: true to defaultOptions in yaml-editor.tsx.

Step 5: Fix schema update lifecycle (revised from original plan) ✅

Original plan: guard useEffect with hasMountedRef. Problem: hasMountedRef was set in beforeMount which runs before effects, so the guard never prevented the initial effect from firing.

Revised approach:

• Use hasInitializedRef (starts false) — the initial effect sets it to true and returns early
• Subsequent schema changes call yamlRef.current.update(monacoYamlOptions) instead of dispose+recreate
• Always provide inline schema (even empty { type: 'object' }) so SchemaHandle never falls back to loadSchema()
• Removed separate fallback schema constant — single buildMonacoYamlOptions() helper handles both cases

Step 6: Fix MonacoEnvironment race ✅

Moved window.MonacoEnvironment = { getWorkerUrl(...) {...} } before loader.init() in config.ts.

Step 7: Verify

Test on both old and new editors:

• Hover tooltips show content (not just border)
• Autocomplete shows schema-driven suggestions in new editor
• Inline validation errors appear in new editor
• No "Unable to load schema" error on first line

Editor Comparison: Old (PipelinesYamlEditor) vs New (YamlEditor)

Aspect	Old (PipelinesYamlEditor)	New (YamlEditor + YamlEditorCard)
Schema	Static JSON import (rp-connect-schema.json)	Dynamic prop, with minimal fallback
configureMonacoYaml timing	beforeMount	onMount + reactive useEffect
path prop	path="new-connector.yaml"	None (model URI won't match fileMatch)
Schema reactivity	No updates after mount	Reconfigures when schema prop changes
Disposal	Simple useEffect cleanup	Two-phase (reconfigure + unmount)
Wrapper	Direct usage, kowlEditor class	Card with header/buttons, overflow-hidden
Expandable	No	Yes, via ExpandedYamlDialog
Linting UI	Separate implementation	Built into card

Usage Locations

Old PipelinesYamlEditor:

• pipelines-create.tsx — CREATE mode (with secrets autocomplete)
• pipelines-details.tsx — VIEW mode (read-only, 400px height)
• redpanda-connect-intro.tsx — interactive demo

New YamlEditorCard:

• pipeline/index.tsx — CREATE/EDIT/VIEW (dynamic schema from backend)
• mcp-servers/create/tool-card.tsx — EDIT (no schema passed)
• mcp-servers/details/remote-mcp-configuration-tab.tsx — EDIT/VIEW (no schema passed)
• expanded-yaml-dialog.tsx — expanded dialog (no schema passed)

Tradeoffs

• Old editor: Works out of the box for Redpanda Connect pipelines. Static schema means no loading delay. But inflexible — same schema for all uses, no card wrapper, no expand.
• New editor: Flexible — dynamic schema, card UI, expandable. But currently broken because of missing path prop and onMount timing. Once fixed, it's strictly better for new development.
• Recommendation: Fix the new editor, then migrate remaining old editor usages over time. The new editor's dynamic schema support is needed for MCP servers and future use cases.

CSS Collision Audit: tw-animate-css & Tailwind Preflight vs Monaco

tw-animate-css Collisions

Class	Risk	Details
fade-in	HIGH — PATCHED	tw-animate-css sets opacity:0; breaks Monaco hover widgets
hidden	LOW	Both set display: none — behavior matches, no visible bug
invisible	LOW	Different mechanisms (Tailwind: visibility: hidden, Monaco: opacity: 0) but Monaco scopes with child combinator
keyframes	NONE	No name collisions between tw-animate-css and Monaco

Tailwind v4 Preflight Impacts

Reset	Risk	Details
h1-h6 { font-size/weight: inherit }	MEDIUM	Monaco hover Markdown content (JSDoc tooltips) loses heading hierarchy. Monaco sets line-height but relies on browser defaults for size/weight
img, svg { display: block }	MEDIUM	Codicon SVGs inside Monaco may shift to block layout if not explicitly styled
ol, ul { list-style: none }	LOW-MEDIUM	Markdown bullet lists in Monaco hover content lose bullets
a { color: inherit }	LOW	Monaco mostly overrides via CSS vars; unstyled links inherit parent color
button/input resets	LOW	Monaco overrides at higher specificity
* { border: 0 solid }	LOW	Monaco sets borders explicitly everywhere

Action: The preflight issues are cosmetic and only affect rich Markdown content in hover tooltips (JSDoc, etc.). Not blocking for YAML editor use case. Can be addressed later with scoped CSS if needed.

Key Files

File	Role
src/components/ui/yaml/yaml-editor.tsx	New YamlEditor component (broken)
src/components/ui/yaml/yaml-editor-card.tsx	Card wrapper with overflow-hidden
src/components/misc/pipelines-yaml-editor.tsx	Old editor (works — reference implementation)
src/config.ts	Monaco loader config and MonacoEnvironment setup
rsbuild.config.ts	MonacoWebpackPlugin with customLanguages
src/components/redpanda-ui/style/theme.css	Tailwind v4 base layer reset

Open Risks

• Worker loading: if yaml.worker.js isn't loading, intellisense fixes won't help — verify in DevTools Network tab
• Multiple editor instances: if path collision causes issues with multiple simultaneous editors, may need unique paths

Known Unknowns

• Is there only one copy of monaco-editor in node_modules? → Verify with bun pm ls monaco-editor
• Will MCP server editors need schema support in the future? → Currently using fallback schema, may need dynamic schema later

References

• monaco-yaml README
• monaco-yaml Issue #92 - Completion not working
• monaco-editor Issue #2229 - Strange widget behavior with fixedOverflowWidgets
• monaco-editor Issue #1588 - overflow: hidden clipping
• monaco-editor-webpack-plugin Issue #135 - getWorker doesn't fire for custom language

[eblairmckee]

@claude please review

[claude]

Claude finished @eblairmckee's task in 1m 44s —— View job

---

Code Review

• Gather context and read changed files
• Review yaml-editor.tsx
• Review config.ts
• Review globals.css
• Post final review

---

Overall, this is a well-researched, well-documented PR with targeted, minimal fixes. The root cause analysis is thorough. A few things worth discussing:

yaml-editor.tsx

hasInitializedRef approach works but is non-obvious (yaml-editor.tsx:93,101-105)

The ref starts false, the first effect call sets it true and returns early (skipping update()), and subsequent schema changes call update(). This is correct and avoids the double-configure race. A short comment explaining why the first call is skipped would help future readers — i.e. "skip first run because configureMonacoYaml already ran in beforeMount".

Static path="pipeline.yaml" shared across all instances (yaml-editor.tsx:127)

The PR notes this in "Open Risks". Monaco models are keyed by URI, so two simultaneously mounted YamlEditor instances would share the same model. In practice this seems to be acceptable since configureMonacoYaml is global anyway, but it's fragile. A low-risk improvement: accept an optional path prop (defaulting to "pipeline.yaml") so callers can override it if needed. Could be a follow-up.

useMemo dependency on schema object reference (yaml-editor.tsx:95-98)

If a parent passes schema={{ definitions: ..., properties: ... }} as an inline object literal, every parent re-render creates a new reference, causing useMemo to recompute and update() to fire unnecessarily. This is a pre-existing concern and not introduced here, but worth noting. If update() is heavyweight (it restarts the YAML worker), callers should stabilize the schema reference with their own useMemo/useState.

**/*.yml added to fileMatch (yaml-editor.tsx:81)

The old editor only matched **/*.yaml. The new one also matches **/*.yml. Not a bug, but a behavior change worth noting — any .yml files opened in this editor instance will also get schema-driven completions.

---

config.ts

loader.init() removed — add a comment (config.ts:413)

Previously window.MonacoEnvironment was set inside loader.init().then(...). The new code correctly sets it synchronously before loader.config({ monaco }), and omits the explicit loader.init() call entirely (it's called internally by @monaco-editor/react's <Editor> component). The behavior is correct, but dropping loader.init() without explanation may confuse someone later who expects to see it. A one-line comment like // loader.init() is called internally by @monaco-editor/react would help.

getWorkerUrl uses hardcoded /static/js/ path (config.ts:398-409)

This predates this PR, but worth noting: the worker paths are hardcoded to /static/js/${label}.worker.js. If assetsPath or __webpack_public_path__ differs from the server root, the workers won't load. The PR description notes this is "MEDIUM" confidence for the race condition fix — verifying in DevTools Network tab that yaml.worker.js loads with a 200 is the key verification step.

---

globals.css

The fix is correct and minimal. .monaco-hover.fade-in has higher specificity than .fade-in and overrides the opacity: 0 from tw-animate-css. The comment explaining the collision is helpful. ✅

The PR's CSS audit table identified hidden, invisible, and Tailwind preflight impacts as LOW/LOW-MEDIUM risk — those seem fine to defer.

---

Summary

Area	Finding	Severity
yaml-editor.tsx	hasInitializedRef logic correct but add a comment	Low
yaml-editor.tsx	Static path prop shared across instances	Low (noted as open risk)
yaml-editor.tsx	schema reference instability → spurious update()	Low (pre-existing)
config.ts	Add comment explaining omitted loader.init()	Low
globals.css	CSS override is correct ✅	—

These are all minor. The core fixes (CSS override, path prop, beforeMount timing, fixedOverflowWidgets, update() API, synchronous MonacoEnvironment, URI normalization) are all sound and well-justified. LGTM with the minor suggestions above.

[malinskibeniamin]

Now that it is working, it would be great to add some type of test (I guess in this case visual test would be best) to make sure monaco editor with schema provided will give you good autocomplete suggestions.

[sago2k8]

@claude could you review and double check removing yamlRef.current.dispose(); is not a breaking change.

[claude]

Claude finished @sago2k8's task in 1m 21s —— View job

---

Review: Is removing yamlRef.current.dispose() a breaking change?

• Read yaml-editor.tsx
• Check git diff
• Analyze dispose() usage and impact
• Post findings

---

Short answer: No, it is not a breaking change. The removal is intentional and correct. Here's why:

What changed

The old schema-update flow (before this PR):

// useEffect on schema change
yamlRef.current.dispose();                          // tear down
yamlRef.current = configureMonacoYaml(monaco, newOpts); // recreate

The new schema-update flow (this PR):

// useEffect on schema change
yamlRef.current?.update(monacoYamlOptions);         // update in place

Why it's safe

1. dispose() on unmount is still there.
yaml-editor.tsx:111-117 still has the cleanup effect:

useEffect(() => {
  return () => {
    if (yamlRef.current) {
      yamlRef.current.dispose();   // ← still present
    }
  };
}, []);

The MonacoYaml instance is always properly cleaned up when the component unmounts. The only dispose() that was removed is the one that ran before recreating the instance on schema updates.

2. update() is the intended API for schema changes.
update() exists specifically to reconfigure the existing MonacoYaml instance without tearing it down. The old dispose+recreate pattern was actually suboptimal:

• It created a brief window where no YAML configuration existed (between dispose() and configureMonacoYaml())
• This could cause the schema request error described in Root Cause 7, since SchemaHandle would be in an empty state momentarily
• Monaco-yaml docs note: "There may only be one configured instance at a time" — update() keeps the instance count at exactly one throughout

3. No memory leak.
yamlRef.current holds the single MonacoYaml instance created in beforeMount. It is never replaced during schema updates (the ref value stays the same), so there's nothing to leak. The instance is disposed once, at unmount.

4. The hasInitializedRef guard is correct.
The first effect run sets hasInitializedRef.current = true and returns early (skipping update()), because configureMonacoYaml was already called in beforeMount. Subsequent schema changes call update() instead. This avoids the double-configure race described in Root Cause 5.

Summary

Old code	New code
Schema update: dispose() + configureMonacoYaml()	Schema update: update()
Unmount: dispose() ✅	Unmount: dispose() ✅

The dispose() removal from the schema update path is strictly better — it uses the purpose-built update() API, avoids a timing gap, and keeps exactly one MonacoYaml instance alive at all times. No breaking change.

[malinskibeniamin]

Ideally we could try and add a test that verifies these files exist in the build/bundle.

[eblairmckee]

Good call — I looked into this. The challenge is that vitest runs in node/jsdom where workers don't exist and there's no build output to inspect. The most practical option would be a post-build CI step that asserts worker files exist in build/static/js/. However, that requires building first and would need a new test:build script + CI step. For now, the MonacoWebpackPlugin config is the source of truth for what gets emitted — if the filename pattern or languages list changes there, the workers change. Adding to our backlog to add a post-build check for this, or defer until we decide on a replacement for monaco.

[eblairmckee]

Adding this requirement to the existing ticket https://redpandadata.atlassian.net/browse/UX-589

[malinskibeniamin]

do we need to add it to the host app too?

[eblairmckee]

like cloudv2? no clue. depends on what order the css stylesheets are loaded.

[malinskibeniamin]

No worries, just double checking we don't get any CSS interference in embedded mode.

[eblairmckee]

Now that it is working, it would be great to add some type of test (I guess in this case visual test would be best) to make sure monaco editor with schema provided will give you good autocomplete suggestions.

@malinskibeniamin

unfortunately they're not "good" right now as they are literally just key autocompletions. until we get the bloblang/connect schema aware LSP (WIP by connect team) it's literally just autocomplete for keys in the rp-connect-schema.json file

I did consider adding an intergration test, but hesitated due to web workers + vitest potentially being flakey (but tbh, I didn't look into it yet).

[secpanda]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.