UI: Fix Monaco workers crashing in production mode by pierrejeambrun · Pull Request #67546 · apache/airflow

pierrejeambrun · 2026-05-26T11:14:02Z

Follow-up to #67352. In production builds, the Monaco editor was unable to spawn its web workers — Chrome logged Could not create web worker(s). Falling back to loading web worker code in main thread. plus MIME-type errors for editor/editor.worker.js, and the JSON editor in XComs / Audit Log was running everything (syntax service, folding) on the UI thread.

Root cause

#67352 switched the worker imports from ?worker to ?url so a Blob shim could re-import them same-origin. ?url, however, does not run Vite's worker pipeline:

For editor.worker.js (the entry source is ~1 KB), ?url inlines the raw module as a base64 data URL via build.assetsInlineLimit. The inlined module still contains bare-specifier imports (vs/editor/...) that cannot be resolved inside a module Worker.
For json.worker.js it copies a partly-bundled file whose top-level import '../../editor/editor.worker.js' resolves to a path that does not exist in the build output.

In both cases the Worker fails to evaluate, Monaco's fallback path kicks in, and the unhashed editor/editor.worker.js URL Monaco tries next hits the SPA HTML fallback (the MIME error).

Fix

Switch the imports to ?worker&url. Vite's worker plugin runs the file through the full worker pipeline (bundling all dependencies into a self-contained IIFE), and the &url suffix returns the bundled file's URL as a string instead of a Worker constructor — which is what the Blob shim needs.

Verified the rebuilt dist/ now contains self-contained workers (editor.worker-<hash>.js ≈ 260 KB, json.worker-<hash>.js ≈ 390 KB, zero top-level imports), with small URL-wrapper modules pointing at them.

Prod:

Screen.Recording.2026-05-26.at.13.18.24.mov

Dev:

Screen.Recording.2026-05-26.at.13.22.37.mov

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 4.7)

Generated-by: Claude Code (Opus 4.7) following the guidelines

`?url` does not run the Vite worker pipeline. For `editor.worker.js` it inlines the raw source as a base64 data URL (the source is below the default `assetsInlineLimit`), and the inlined module still has bare specifier imports it cannot resolve in a Worker context. For `json.worker.js` it copies a partly-bundled file whose top-level `import '../../editor/editor.worker.js'` resolves to a path that does not exist in the build output. Both cases manifest at runtime as "Could not create web worker(s). Falling back to loading web worker code in main thread" followed by a stream of fallback fetch errors. Switch to `?worker&url`: Vite runs the file through the worker pipeline (bundling all dependencies into a self-contained IIFE) and the URL query suffix returns the resulting URL as a string instead of a Worker constructor. The Blob shim from apache#67352 then imports a properly bundled worker, restoring real worker-thread execution.

pierrejeambrun · 2026-05-26T11:33:51Z

I'm opening a follow up PR for the unrelated console errors we see in the 'prod' example.

choo121600 · 2026-05-26T12:36:13Z

nit, I wonder if some comments could be shortened a bit, but this is non-blocking

github-actions · 2026-05-26T13:58:21Z

Backport failed to create: v3-2-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-2-test

You can attempt to backport this manually by running:

cherry_picker 021606f v3-2-test

This should apply the commit to the v3-2-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

`?url` does not run the Vite worker pipeline. For `editor.worker.js` it inlines the raw source as a base64 data URL (the source is below the default `assetsInlineLimit`), and the inlined module still has bare specifier imports it cannot resolve in a Worker context. For `json.worker.js` it copies a partly-bundled file whose top-level `import '../../editor/editor.worker.js'` resolves to a path that does not exist in the build output. Both cases manifest at runtime as "Could not create web worker(s). Falling back to loading web worker code in main thread" followed by a stream of fallback fetch errors. Switch to `?worker&url`: Vite runs the file through the worker pipeline (bundling all dependencies into a self-contained IIFE) and the URL query suffix returns the resulting URL as a string instead of a Worker constructor. The Blob shim from apache#67352 then imports a properly bundled worker, restoring real worker-thread execution. Co-authored-by: Rahul Vats <43964496+vatsrahul1001@users.noreply.github.com>

pierrejeambrun · 2026-05-26T11:14:02Z

Follow-up to #67352. In production builds, the Monaco editor was unable to spawn its web workers — Chrome logged Could not create web worker(s). Falling back to loading web worker code in main thread. plus MIME-type errors for editor/editor.worker.js, and the JSON editor in XComs / Audit Log was running everything (syntax service, folding) on the UI thread.

Root cause

#67352 switched the worker imports from ?worker to ?url so a Blob shim could re-import them same-origin. ?url, however, does not run Vite's worker pipeline:

For editor.worker.js (the entry source is ~1 KB), ?url inlines the raw module as a base64 data URL via build.assetsInlineLimit. The inlined module still contains bare-specifier imports (vs/editor/...) that cannot be resolved inside a module Worker.
For json.worker.js it copies a partly-bundled file whose top-level import '../../editor/editor.worker.js' resolves to a path that does not exist in the build output.

In both cases the Worker fails to evaluate, Monaco's fallback path kicks in, and the unhashed editor/editor.worker.js URL Monaco tries next hits the SPA HTML fallback (the MIME error).

Fix

Switch the imports to ?worker&url. Vite's worker plugin runs the file through the full worker pipeline (bundling all dependencies into a self-contained IIFE), and the &url suffix returns the bundled file's URL as a string instead of a Worker constructor — which is what the Blob shim needs.

Verified the rebuilt dist/ now contains self-contained workers (editor.worker-<hash>.js ≈ 260 KB, json.worker-<hash>.js ≈ 390 KB, zero top-level imports), with small URL-wrapper modules pointing at them.

Prod:

Screen.Recording.2026-05-26.at.13.18.24.mov

Dev:

Screen.Recording.2026-05-26.at.13.22.37.mov

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 4.7)

Generated-by: Claude Code (Opus 4.7) following the guidelines

`?url` does not run the Vite worker pipeline. For `editor.worker.js` it inlines the raw source as a base64 data URL (the source is below the default `assetsInlineLimit`), and the inlined module still has bare specifier imports it cannot resolve in a Worker context. For `json.worker.js` it copies a partly-bundled file whose top-level `import '../../editor/editor.worker.js'` resolves to a path that does not exist in the build output. Both cases manifest at runtime as "Could not create web worker(s). Falling back to loading web worker code in main thread" followed by a stream of fallback fetch errors. Switch to `?worker&url`: Vite runs the file through the worker pipeline (bundling all dependencies into a self-contained IIFE) and the URL query suffix returns the resulting URL as a string instead of a Worker constructor. The Blob shim from apache#67352 then imports a properly bundled worker, restoring real worker-thread execution.

pierrejeambrun · 2026-05-26T11:33:51Z

I'm opening a follow up PR for the unrelated console errors we see in the 'prod' example.

choo121600 · 2026-05-26T12:36:13Z

nit, I wonder if some comments could be shortened a bit, but this is non-blocking

github-actions · 2026-05-26T13:58:21Z

Backport failed to create: v3-2-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-2-test

You can attempt to backport this manually by running:

cherry_picker 021606f v3-2-test

This should apply the commit to the v3-2-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

`?url` does not run the Vite worker pipeline. For `editor.worker.js` it inlines the raw source as a base64 data URL (the source is below the default `assetsInlineLimit`), and the inlined module still has bare specifier imports it cannot resolve in a Worker context. For `json.worker.js` it copies a partly-bundled file whose top-level `import '../../editor/editor.worker.js'` resolves to a path that does not exist in the build output. Both cases manifest at runtime as "Could not create web worker(s). Falling back to loading web worker code in main thread" followed by a stream of fallback fetch errors. Switch to `?worker&url`: Vite runs the file through the worker pipeline (bundling all dependencies into a self-contained IIFE) and the URL query suffix returns the resulting URL as a string instead of a Worker constructor. The Blob shim from apache#67352 then imports a properly bundled worker, restoring real worker-thread execution. Co-authored-by: Rahul Vats <43964496+vatsrahul1001@users.noreply.github.com>

pierrejeambrun · 2026-05-26T11:14:02Z

Follow-up to #67352. In production builds, the Monaco editor was unable to spawn its web workers — Chrome logged Could not create web worker(s). Falling back to loading web worker code in main thread. plus MIME-type errors for editor/editor.worker.js, and the JSON editor in XComs / Audit Log was running everything (syntax service, folding) on the UI thread.

Root cause

#67352 switched the worker imports from ?worker to ?url so a Blob shim could re-import them same-origin. ?url, however, does not run Vite's worker pipeline:

For editor.worker.js (the entry source is ~1 KB), ?url inlines the raw module as a base64 data URL via build.assetsInlineLimit. The inlined module still contains bare-specifier imports (vs/editor/...) that cannot be resolved inside a module Worker.
For json.worker.js it copies a partly-bundled file whose top-level import '../../editor/editor.worker.js' resolves to a path that does not exist in the build output.

In both cases the Worker fails to evaluate, Monaco's fallback path kicks in, and the unhashed editor/editor.worker.js URL Monaco tries next hits the SPA HTML fallback (the MIME error).

Fix

Switch the imports to ?worker&url. Vite's worker plugin runs the file through the full worker pipeline (bundling all dependencies into a self-contained IIFE), and the &url suffix returns the bundled file's URL as a string instead of a Worker constructor — which is what the Blob shim needs.

Verified the rebuilt dist/ now contains self-contained workers (editor.worker-<hash>.js ≈ 260 KB, json.worker-<hash>.js ≈ 390 KB, zero top-level imports), with small URL-wrapper modules pointing at them.

Prod:

Screen.Recording.2026-05-26.at.13.18.24.mov

Dev:

Screen.Recording.2026-05-26.at.13.22.37.mov

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 4.7)

Generated-by: Claude Code (Opus 4.7) following the guidelines

`?url` does not run the Vite worker pipeline. For `editor.worker.js` it inlines the raw source as a base64 data URL (the source is below the default `assetsInlineLimit`), and the inlined module still has bare specifier imports it cannot resolve in a Worker context. For `json.worker.js` it copies a partly-bundled file whose top-level `import '../../editor/editor.worker.js'` resolves to a path that does not exist in the build output. Both cases manifest at runtime as "Could not create web worker(s). Falling back to loading web worker code in main thread" followed by a stream of fallback fetch errors. Switch to `?worker&url`: Vite runs the file through the worker pipeline (bundling all dependencies into a self-contained IIFE) and the URL query suffix returns the resulting URL as a string instead of a Worker constructor. The Blob shim from apache#67352 then imports a properly bundled worker, restoring real worker-thread execution.

pierrejeambrun · 2026-05-26T11:33:51Z

I'm opening a follow up PR for the unrelated console errors we see in the 'prod' example.

choo121600 · 2026-05-26T12:36:13Z

nit, I wonder if some comments could be shortened a bit, but this is non-blocking

github-actions · 2026-05-26T13:58:21Z

Backport failed to create: v3-2-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-2-test

You can attempt to backport this manually by running:

cherry_picker 021606f v3-2-test

This should apply the commit to the v3-2-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

`?url` does not run the Vite worker pipeline. For `editor.worker.js` it inlines the raw source as a base64 data URL (the source is below the default `assetsInlineLimit`), and the inlined module still has bare specifier imports it cannot resolve in a Worker context. For `json.worker.js` it copies a partly-bundled file whose top-level `import '../../editor/editor.worker.js'` resolves to a path that does not exist in the build output. Both cases manifest at runtime as "Could not create web worker(s). Falling back to loading web worker code in main thread" followed by a stream of fallback fetch errors. Switch to `?worker&url`: Vite runs the file through the worker pipeline (bundling all dependencies into a self-contained IIFE) and the URL query suffix returns the resulting URL as a string instead of a Worker constructor. The Blob shim from apache#67352 then imports a properly bundled worker, restoring real worker-thread execution. Co-authored-by: Rahul Vats <43964496+vatsrahul1001@users.noreply.github.com>

pierrejeambrun · 2026-05-26T11:14:02Z

Follow-up to #67352. In production builds, the Monaco editor was unable to spawn its web workers — Chrome logged Could not create web worker(s). Falling back to loading web worker code in main thread. plus MIME-type errors for editor/editor.worker.js, and the JSON editor in XComs / Audit Log was running everything (syntax service, folding) on the UI thread.

Root cause

#67352 switched the worker imports from ?worker to ?url so a Blob shim could re-import them same-origin. ?url, however, does not run Vite's worker pipeline:

For editor.worker.js (the entry source is ~1 KB), ?url inlines the raw module as a base64 data URL via build.assetsInlineLimit. The inlined module still contains bare-specifier imports (vs/editor/...) that cannot be resolved inside a module Worker.
For json.worker.js it copies a partly-bundled file whose top-level import '../../editor/editor.worker.js' resolves to a path that does not exist in the build output.

In both cases the Worker fails to evaluate, Monaco's fallback path kicks in, and the unhashed editor/editor.worker.js URL Monaco tries next hits the SPA HTML fallback (the MIME error).

Fix

Switch the imports to ?worker&url. Vite's worker plugin runs the file through the full worker pipeline (bundling all dependencies into a self-contained IIFE), and the &url suffix returns the bundled file's URL as a string instead of a Worker constructor — which is what the Blob shim needs.

Verified the rebuilt dist/ now contains self-contained workers (editor.worker-<hash>.js ≈ 260 KB, json.worker-<hash>.js ≈ 390 KB, zero top-level imports), with small URL-wrapper modules pointing at them.

Prod:

Screen.Recording.2026-05-26.at.13.18.24.mov

Dev:

Screen.Recording.2026-05-26.at.13.22.37.mov

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 4.7)

Generated-by: Claude Code (Opus 4.7) following the guidelines

`?url` does not run the Vite worker pipeline. For `editor.worker.js` it inlines the raw source as a base64 data URL (the source is below the default `assetsInlineLimit`), and the inlined module still has bare specifier imports it cannot resolve in a Worker context. For `json.worker.js` it copies a partly-bundled file whose top-level `import '../../editor/editor.worker.js'` resolves to a path that does not exist in the build output. Both cases manifest at runtime as "Could not create web worker(s). Falling back to loading web worker code in main thread" followed by a stream of fallback fetch errors. Switch to `?worker&url`: Vite runs the file through the worker pipeline (bundling all dependencies into a self-contained IIFE) and the URL query suffix returns the resulting URL as a string instead of a Worker constructor. The Blob shim from apache#67352 then imports a properly bundled worker, restoring real worker-thread execution.

pierrejeambrun · 2026-05-26T11:33:51Z

I'm opening a follow up PR for the unrelated console errors we see in the 'prod' example.

choo121600 · 2026-05-26T12:36:13Z

nit, I wonder if some comments could be shortened a bit, but this is non-blocking

github-actions · 2026-05-26T13:58:21Z

Backport failed to create: v3-2-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-2-test

You can attempt to backport this manually by running:

cherry_picker 021606f v3-2-test

This should apply the commit to the v3-2-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

`?url` does not run the Vite worker pipeline. For `editor.worker.js` it inlines the raw source as a base64 data URL (the source is below the default `assetsInlineLimit`), and the inlined module still has bare specifier imports it cannot resolve in a Worker context. For `json.worker.js` it copies a partly-bundled file whose top-level `import '../../editor/editor.worker.js'` resolves to a path that does not exist in the build output. Both cases manifest at runtime as "Could not create web worker(s). Falling back to loading web worker code in main thread" followed by a stream of fallback fetch errors. Switch to `?worker&url`: Vite runs the file through the worker pipeline (bundling all dependencies into a self-contained IIFE) and the URL query suffix returns the resulting URL as a string instead of a Worker constructor. The Blob shim from apache#67352 then imports a properly bundled worker, restoring real worker-thread execution. Co-authored-by: Rahul Vats <43964496+vatsrahul1001@users.noreply.github.com>

pierrejeambrun · 2026-05-26T11:14:02Z

Follow-up to #67352. In production builds, the Monaco editor was unable to spawn its web workers — Chrome logged Could not create web worker(s). Falling back to loading web worker code in main thread. plus MIME-type errors for editor/editor.worker.js, and the JSON editor in XComs / Audit Log was running everything (syntax service, folding) on the UI thread.

Root cause

#67352 switched the worker imports from ?worker to ?url so a Blob shim could re-import them same-origin. ?url, however, does not run Vite's worker pipeline:

For editor.worker.js (the entry source is ~1 KB), ?url inlines the raw module as a base64 data URL via build.assetsInlineLimit. The inlined module still contains bare-specifier imports (vs/editor/...) that cannot be resolved inside a module Worker.
For json.worker.js it copies a partly-bundled file whose top-level import '../../editor/editor.worker.js' resolves to a path that does not exist in the build output.

In both cases the Worker fails to evaluate, Monaco's fallback path kicks in, and the unhashed editor/editor.worker.js URL Monaco tries next hits the SPA HTML fallback (the MIME error).

Fix

Switch the imports to ?worker&url. Vite's worker plugin runs the file through the full worker pipeline (bundling all dependencies into a self-contained IIFE), and the &url suffix returns the bundled file's URL as a string instead of a Worker constructor — which is what the Blob shim needs.

Verified the rebuilt dist/ now contains self-contained workers (editor.worker-<hash>.js ≈ 260 KB, json.worker-<hash>.js ≈ 390 KB, zero top-level imports), with small URL-wrapper modules pointing at them.

Prod:

Screen.Recording.2026-05-26.at.13.18.24.mov

Dev:

Screen.Recording.2026-05-26.at.13.22.37.mov

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 4.7)

Generated-by: Claude Code (Opus 4.7) following the guidelines

`?url` does not run the Vite worker pipeline. For `editor.worker.js` it inlines the raw source as a base64 data URL (the source is below the default `assetsInlineLimit`), and the inlined module still has bare specifier imports it cannot resolve in a Worker context. For `json.worker.js` it copies a partly-bundled file whose top-level `import '../../editor/editor.worker.js'` resolves to a path that does not exist in the build output. Both cases manifest at runtime as "Could not create web worker(s). Falling back to loading web worker code in main thread" followed by a stream of fallback fetch errors. Switch to `?worker&url`: Vite runs the file through the worker pipeline (bundling all dependencies into a self-contained IIFE) and the URL query suffix returns the resulting URL as a string instead of a Worker constructor. The Blob shim from apache#67352 then imports a properly bundled worker, restoring real worker-thread execution.

pierrejeambrun · 2026-05-26T11:33:51Z

I'm opening a follow up PR for the unrelated console errors we see in the 'prod' example.

choo121600 · 2026-05-26T12:36:13Z

nit, I wonder if some comments could be shortened a bit, but this is non-blocking

github-actions · 2026-05-26T13:58:21Z

Backport failed to create: v3-2-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-2-test

You can attempt to backport this manually by running:

cherry_picker 021606f v3-2-test

This should apply the commit to the v3-2-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

`?url` does not run the Vite worker pipeline. For `editor.worker.js` it inlines the raw source as a base64 data URL (the source is below the default `assetsInlineLimit`), and the inlined module still has bare specifier imports it cannot resolve in a Worker context. For `json.worker.js` it copies a partly-bundled file whose top-level `import '../../editor/editor.worker.js'` resolves to a path that does not exist in the build output. Both cases manifest at runtime as "Could not create web worker(s). Falling back to loading web worker code in main thread" followed by a stream of fallback fetch errors. Switch to `?worker&url`: Vite runs the file through the worker pipeline (bundling all dependencies into a self-contained IIFE) and the URL query suffix returns the resulting URL as a string instead of a Worker constructor. The Blob shim from apache#67352 then imports a properly bundled worker, restoring real worker-thread execution. Co-authored-by: Rahul Vats <43964496+vatsrahul1001@users.noreply.github.com>

pierrejeambrun · 2026-05-26T11:14:02Z

Follow-up to #67352. In production builds, the Monaco editor was unable to spawn its web workers — Chrome logged Could not create web worker(s). Falling back to loading web worker code in main thread. plus MIME-type errors for editor/editor.worker.js, and the JSON editor in XComs / Audit Log was running everything (syntax service, folding) on the UI thread.

Root cause

#67352 switched the worker imports from ?worker to ?url so a Blob shim could re-import them same-origin. ?url, however, does not run Vite's worker pipeline:

For editor.worker.js (the entry source is ~1 KB), ?url inlines the raw module as a base64 data URL via build.assetsInlineLimit. The inlined module still contains bare-specifier imports (vs/editor/...) that cannot be resolved inside a module Worker.
For json.worker.js it copies a partly-bundled file whose top-level import '../../editor/editor.worker.js' resolves to a path that does not exist in the build output.

In both cases the Worker fails to evaluate, Monaco's fallback path kicks in, and the unhashed editor/editor.worker.js URL Monaco tries next hits the SPA HTML fallback (the MIME error).

Fix

Switch the imports to ?worker&url. Vite's worker plugin runs the file through the full worker pipeline (bundling all dependencies into a self-contained IIFE), and the &url suffix returns the bundled file's URL as a string instead of a Worker constructor — which is what the Blob shim needs.

Verified the rebuilt dist/ now contains self-contained workers (editor.worker-<hash>.js ≈ 260 KB, json.worker-<hash>.js ≈ 390 KB, zero top-level imports), with small URL-wrapper modules pointing at them.

Prod:

Screen.Recording.2026-05-26.at.13.18.24.mov

Dev:

Screen.Recording.2026-05-26.at.13.22.37.mov

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 4.7)

Generated-by: Claude Code (Opus 4.7) following the guidelines

`?url` does not run the Vite worker pipeline. For `editor.worker.js` it inlines the raw source as a base64 data URL (the source is below the default `assetsInlineLimit`), and the inlined module still has bare specifier imports it cannot resolve in a Worker context. For `json.worker.js` it copies a partly-bundled file whose top-level `import '../../editor/editor.worker.js'` resolves to a path that does not exist in the build output. Both cases manifest at runtime as "Could not create web worker(s). Falling back to loading web worker code in main thread" followed by a stream of fallback fetch errors. Switch to `?worker&url`: Vite runs the file through the worker pipeline (bundling all dependencies into a self-contained IIFE) and the URL query suffix returns the resulting URL as a string instead of a Worker constructor. The Blob shim from apache#67352 then imports a properly bundled worker, restoring real worker-thread execution.

pierrejeambrun · 2026-05-26T11:33:51Z

I'm opening a follow up PR for the unrelated console errors we see in the 'prod' example.

choo121600 · 2026-05-26T12:36:13Z

nit, I wonder if some comments could be shortened a bit, but this is non-blocking

github-actions · 2026-05-26T13:58:21Z

Backport failed to create: v3-2-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-2-test

You can attempt to backport this manually by running:

cherry_picker 021606f v3-2-test

This should apply the commit to the v3-2-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

`?url` does not run the Vite worker pipeline. For `editor.worker.js` it inlines the raw source as a base64 data URL (the source is below the default `assetsInlineLimit`), and the inlined module still has bare specifier imports it cannot resolve in a Worker context. For `json.worker.js` it copies a partly-bundled file whose top-level `import '../../editor/editor.worker.js'` resolves to a path that does not exist in the build output. Both cases manifest at runtime as "Could not create web worker(s). Falling back to loading web worker code in main thread" followed by a stream of fallback fetch errors. Switch to `?worker&url`: Vite runs the file through the worker pipeline (bundling all dependencies into a self-contained IIFE) and the URL query suffix returns the resulting URL as a string instead of a Worker constructor. The Blob shim from apache#67352 then imports a properly bundled worker, restoring real worker-thread execution. Co-authored-by: Rahul Vats <43964496+vatsrahul1001@users.noreply.github.com>

pierrejeambrun · 2026-05-26T11:14:02Z

Follow-up to #67352. In production builds, the Monaco editor was unable to spawn its web workers — Chrome logged Could not create web worker(s). Falling back to loading web worker code in main thread. plus MIME-type errors for editor/editor.worker.js, and the JSON editor in XComs / Audit Log was running everything (syntax service, folding) on the UI thread.

Root cause

#67352 switched the worker imports from ?worker to ?url so a Blob shim could re-import them same-origin. ?url, however, does not run Vite's worker pipeline:

For editor.worker.js (the entry source is ~1 KB), ?url inlines the raw module as a base64 data URL via build.assetsInlineLimit. The inlined module still contains bare-specifier imports (vs/editor/...) that cannot be resolved inside a module Worker.
For json.worker.js it copies a partly-bundled file whose top-level import '../../editor/editor.worker.js' resolves to a path that does not exist in the build output.

In both cases the Worker fails to evaluate, Monaco's fallback path kicks in, and the unhashed editor/editor.worker.js URL Monaco tries next hits the SPA HTML fallback (the MIME error).

Fix

Switch the imports to ?worker&url. Vite's worker plugin runs the file through the full worker pipeline (bundling all dependencies into a self-contained IIFE), and the &url suffix returns the bundled file's URL as a string instead of a Worker constructor — which is what the Blob shim needs.

Verified the rebuilt dist/ now contains self-contained workers (editor.worker-<hash>.js ≈ 260 KB, json.worker-<hash>.js ≈ 390 KB, zero top-level imports), with small URL-wrapper modules pointing at them.

Prod:

Screen.Recording.2026-05-26.at.13.18.24.mov

Dev:

Screen.Recording.2026-05-26.at.13.22.37.mov

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 4.7)

Generated-by: Claude Code (Opus 4.7) following the guidelines

`?url` does not run the Vite worker pipeline. For `editor.worker.js` it inlines the raw source as a base64 data URL (the source is below the default `assetsInlineLimit`), and the inlined module still has bare specifier imports it cannot resolve in a Worker context. For `json.worker.js` it copies a partly-bundled file whose top-level `import '../../editor/editor.worker.js'` resolves to a path that does not exist in the build output. Both cases manifest at runtime as "Could not create web worker(s). Falling back to loading web worker code in main thread" followed by a stream of fallback fetch errors. Switch to `?worker&url`: Vite runs the file through the worker pipeline (bundling all dependencies into a self-contained IIFE) and the URL query suffix returns the resulting URL as a string instead of a Worker constructor. The Blob shim from apache#67352 then imports a properly bundled worker, restoring real worker-thread execution.

pierrejeambrun · 2026-05-26T11:33:51Z

I'm opening a follow up PR for the unrelated console errors we see in the 'prod' example.

choo121600 · 2026-05-26T12:36:13Z

nit, I wonder if some comments could be shortened a bit, but this is non-blocking

github-actions · 2026-05-26T13:58:21Z

Backport failed to create: v3-2-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-2-test

You can attempt to backport this manually by running:

cherry_picker 021606f v3-2-test

This should apply the commit to the v3-2-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

`?url` does not run the Vite worker pipeline. For `editor.worker.js` it inlines the raw source as a base64 data URL (the source is below the default `assetsInlineLimit`), and the inlined module still has bare specifier imports it cannot resolve in a Worker context. For `json.worker.js` it copies a partly-bundled file whose top-level `import '../../editor/editor.worker.js'` resolves to a path that does not exist in the build output. Both cases manifest at runtime as "Could not create web worker(s). Falling back to loading web worker code in main thread" followed by a stream of fallback fetch errors. Switch to `?worker&url`: Vite runs the file through the worker pipeline (bundling all dependencies into a self-contained IIFE) and the URL query suffix returns the resulting URL as a string instead of a Worker constructor. The Blob shim from apache#67352 then imports a properly bundled worker, restoring real worker-thread execution. Co-authored-by: Rahul Vats <43964496+vatsrahul1001@users.noreply.github.com>

pierrejeambrun · 2026-05-26T11:14:02Z

Follow-up to #67352. In production builds, the Monaco editor was unable to spawn its web workers — Chrome logged Could not create web worker(s). Falling back to loading web worker code in main thread. plus MIME-type errors for editor/editor.worker.js, and the JSON editor in XComs / Audit Log was running everything (syntax service, folding) on the UI thread.

Root cause

#67352 switched the worker imports from ?worker to ?url so a Blob shim could re-import them same-origin. ?url, however, does not run Vite's worker pipeline:

For editor.worker.js (the entry source is ~1 KB), ?url inlines the raw module as a base64 data URL via build.assetsInlineLimit. The inlined module still contains bare-specifier imports (vs/editor/...) that cannot be resolved inside a module Worker.
For json.worker.js it copies a partly-bundled file whose top-level import '../../editor/editor.worker.js' resolves to a path that does not exist in the build output.

In both cases the Worker fails to evaluate, Monaco's fallback path kicks in, and the unhashed editor/editor.worker.js URL Monaco tries next hits the SPA HTML fallback (the MIME error).

Fix

Switch the imports to ?worker&url. Vite's worker plugin runs the file through the full worker pipeline (bundling all dependencies into a self-contained IIFE), and the &url suffix returns the bundled file's URL as a string instead of a Worker constructor — which is what the Blob shim needs.

Verified the rebuilt dist/ now contains self-contained workers (editor.worker-<hash>.js ≈ 260 KB, json.worker-<hash>.js ≈ 390 KB, zero top-level imports), with small URL-wrapper modules pointing at them.

Prod:

Screen.Recording.2026-05-26.at.13.18.24.mov

Dev:

Screen.Recording.2026-05-26.at.13.22.37.mov

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 4.7)

Generated-by: Claude Code (Opus 4.7) following the guidelines

`?url` does not run the Vite worker pipeline. For `editor.worker.js` it inlines the raw source as a base64 data URL (the source is below the default `assetsInlineLimit`), and the inlined module still has bare specifier imports it cannot resolve in a Worker context. For `json.worker.js` it copies a partly-bundled file whose top-level `import '../../editor/editor.worker.js'` resolves to a path that does not exist in the build output. Both cases manifest at runtime as "Could not create web worker(s). Falling back to loading web worker code in main thread" followed by a stream of fallback fetch errors. Switch to `?worker&url`: Vite runs the file through the worker pipeline (bundling all dependencies into a self-contained IIFE) and the URL query suffix returns the resulting URL as a string instead of a Worker constructor. The Blob shim from apache#67352 then imports a properly bundled worker, restoring real worker-thread execution.

pierrejeambrun · 2026-05-26T11:33:51Z

I'm opening a follow up PR for the unrelated console errors we see in the 'prod' example.

choo121600 · 2026-05-26T12:36:13Z

nit, I wonder if some comments could be shortened a bit, but this is non-blocking

github-actions · 2026-05-26T13:58:21Z

Backport failed to create: v3-2-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-2-test

You can attempt to backport this manually by running:

cherry_picker 021606f v3-2-test

This should apply the commit to the v3-2-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

`?url` does not run the Vite worker pipeline. For `editor.worker.js` it inlines the raw source as a base64 data URL (the source is below the default `assetsInlineLimit`), and the inlined module still has bare specifier imports it cannot resolve in a Worker context. For `json.worker.js` it copies a partly-bundled file whose top-level `import '../../editor/editor.worker.js'` resolves to a path that does not exist in the build output. Both cases manifest at runtime as "Could not create web worker(s). Falling back to loading web worker code in main thread" followed by a stream of fallback fetch errors. Switch to `?worker&url`: Vite runs the file through the worker pipeline (bundling all dependencies into a self-contained IIFE) and the URL query suffix returns the resulting URL as a string instead of a Worker constructor. The Blob shim from apache#67352 then imports a properly bundled worker, restoring real worker-thread execution. Co-authored-by: Rahul Vats <43964496+vatsrahul1001@users.noreply.github.com>

boring-cyborgBot added the area:UI Related to UI/UX. For Frontend Developers. label May 26, 2026

pierrejeambrun marked this pull request as ready for review May 26, 2026 11:15

pierrejeambrun requested review from bbovenzi, choo121600, guan404ming, ryanahamilton, shubhamraj-git and vatsrahul1001 as code owners May 26, 2026 11:15

pierrejeambrun added the backport-to-v3-2-test label May 26, 2026

pierrejeambrun modified the milestones: Airflow 3.2.3, Airflow 3.2.2 May 26, 2026

pierrejeambrun mentioned this pull request May 26, 2026
UI: Rewrite modulepreload hrefs to the api-server static path #67548
Merged
1 task

vatsrahul1001 approved these changes May 26, 2026
View reviewed changes

eladkal approved these changes May 26, 2026
View reviewed changes

choo121600 approved these changes May 26, 2026
View reviewed changes

Merge branch 'main' into ui/fix-monaco-worker-bundling
1f95c6b

vatsrahul1001 merged commit 021606f into apache:mainMay 26, 2026
124 of 143 checks passed

vatsrahul1001 deleted the ui/fix-monaco-worker-bundling branch May 26, 2026 13:57

pierrejeambrun mentioned this pull request May 27, 2026
Expand/collapse functionality is not working for XComs/Audit logs #67310
Closed
2 tasks

bbovenzi mentioned this pull request Jun 4, 2026
Remove Monaco Editor #68032
Closed
2 tasks