Skip to content

[SvelteKit 3] Sentry 11.8 build-time instrumentation breaks PostgreSQL bundling in Azure Functions #25470

Open
Open
[SvelteKit 3] Sentry 11.8 build-time instrumentation breaks PostgreSQL bundling in Azure Functions#25470
Labels
BugSvelteKitWaiting for: Product Owner

Description

@ktarmyshov
ktarmyshov
opened on Oct 16, 2026

Is there an existing issue for this?

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/sveltekit

SDK Version

11.8.0

Framework Version

"@sveltejs/kit": "^3.1.0",

Link to Sentry event

https://konstantin-tarmyshov.sentry.io/share/issue/9da37aba11594d27b8c7dcdfc60a1f5e/

Reproduction Example/SDK Setup

[SvelteKit 3] Sentry 11.8 build-time instrumentation breaks PostgreSQL bundling in Azure Functions

Environment

  • Sentry SDK: @sentry/sveltekit@11.8.0
  • SvelteKit: 3.1.0
  • Vite: 8.3.4
  • Rolldown: 1.2.14
  • PostgreSQL driver: pg@8.23.1
  • Deployment: Azure Static Web Apps / Azure Functions, Node.js 22
  • Adapter: @ktarmyshov/svelte-adapter-azure-swa

The adapter uses a two-stage build: SvelteKit/Vite produces the first SSR bundle, then the adapter runs a separate Rolldown pass to generate the deployable Azure Functions output.

Problem

With Sentry enabled, a simple SvelteKit endpoint importing Client from pg fails in Azure:

Error: Cannot find module 'pg-types'
Require stack:
- /home/site/wwwroot/sk_render/_server.ts-<hash>.js

Public Sentry event:

https://konstantin-tarmyshov.sentry.io/share/issue/9da37aba11594d27b8c7dcdfc60a1f5e/

The endpoint does not connect to a database:

import { Client } from 'pg';

export function GET() {
  return new Response(typeof Client);
}

The failure disappears when either:

  1. pg is explicitly externalized during the initial Vite SSR build.
  2. Sentry is completely removed, without any explicit externalization.

Both alternatives have been verified on real Azure deployments, not just local builds.

Three verified Azure experiments

A. Sentry enabled, default SSR configuration — FAIL

Commit:
kt-npm-modules/svelte-adapter-azure-swa@473db3c

Failing Azure job:
https://github.com/kt-npm-modules/svelte-adapter-azure-swa/actions/runs/38960205600/job/117173179946

Result: 39 passed, 1 failed.

The PostgreSQL smoke endpoint returns HTTP 500 instead of 200.

The first Vite SSR stage produces an approximately 801 KB PostgreSQL endpoint bundle containing unresolved CommonJS calls:

__require("pg-types")
__require("pg-protocol")
__require("pgpass")
__require("pg-cloudflare")
__require("pg-connection-string")

These calls survive the adapter's second Rolldown bundling pass and fail during Azure Functions execution.

B. Sentry enabled, ssr.external: ['pg'] — PASS

Commit:
kt-npm-modules/svelte-adapter-azure-swa@7a1f50f

Successful Azure job:
https://github.com/kt-npm-modules/svelte-adapter-azure-swa/actions/runs/38961408425/job/117177863220

Result: 40 passed, including PostgreSQL and both Sentry error-ingestion tests.

Exact comparison of the failing and passing commits:

kt-npm-modules/svelte-adapter-azure-swa@473db3c...7a1f50f

The only functionally relevant change is:

ssr: {
  external: ['pg']
}

The first Vite SSR bundle now retains an ordinary import:

import { Client } from "pg";

The second Rolldown pass successfully bundles PostgreSQL and its dependencies.

However, Sentry explicitly warns:

[Sentry] The following packages are marked as external
in your bundler configuration but need to be bundled
for Sentry instrumentation to work: pg.

Remove them from your bundler's "external" configuration,
or use the Sentry Node SDK's runtime instrumentation instead.

Therefore, the workaround fixes deployment but may prevent automatic PostgreSQL instrumentation.

Passing the Sentry error-ingestion tests does not prove that PostgreSQL performance tracing remains functional.

C. Sentry removed, no ssr.external workaround — PASS

Diagnostic draft PR:
kt-npm-modules/svelte-adapter-azure-swa#335

Successful Azure job:
https://github.com/kt-npm-modules/svelte-adapter-azure-swa/actions/runs/38966384532/job/117194085562

Result: 38 passed, including PostgreSQL.

This experiment completely removes Sentry SDK dependencies, its Vite plugin, hooks, server instrumentation, tracing configuration, and Sentry-specific tests.

The adapter and PostgreSQL smoke endpoint remain unchanged. No ssr.external: ['pg'] workaround is present.

The first Vite SSR PostgreSQL endpoint is now approximately 0.20 KB, and the generated Azure Function works correctly.

This is a broader Sentry-removal experiment, not a Vite-plugin-only isolation. It establishes that the failure disappears without Sentry, but does not identify the exact responsible hook.

Suspected cause

Investigation of the resolved Vite configuration with Sentry enabled showed that pg, pg-pool, and numerous other instrumented packages were present in:

  • ssr.noExternal
  • environments.ssr.resolve.noExternal

This appears to force PostgreSQL into the initial SSR bundle, producing partially bundled CommonJS code with unresolved runtime __require() calls.

Build-time resolver diagnostics confirmed that the PostgreSQL dependencies could be resolved. The unresolved calls are introduced into the generated output.

Without Sentry, Vite leaves PostgreSQL external in the first stage, allowing the downstream bundler to process its original dependency graph.

We suspect Sentry's build-time instrumentation / Orchestrion integration is responsible for this change in externalization behavior. However, the precise plugin hook has not yet been isolated.

Related issues

This appears similar to existing problems with build-time instrumentation in other Sentry framework integrations:

Related Rolldown investigations: [#10643](rolldown/rolldown#10643) and [#9407](rolldown/rolldown#9407).

Expected behavior

Sentry's build-time instrumentation should not cause an otherwise working PostgreSQL dependency to become partially bundled and fail after downstream server bundling.

Ideally, PostgreSQL instrumentation should remain functional without requiring ssr.external: ['pg'].

Questions

  1. Does the SvelteKit Sentry integration intentionally force pg into ssr.noExternal through build-time instrumentation?
  2. Is this the same class of problem addressed for Nuxt in @sentry/nuxt 11: CommonJS packages inlined for build-time instrumentation break in the Nitro bundle #24775, and could the SvelteKit integration require a similar fix?
  3. Is there a supported way to retain PostgreSQL instrumentation in a two-stage SvelteKit/Azure Functions build without forcing pg to be external?

All three configurations have publicly accessible commits and successful or failing real Azure E2E jobs.

The diagnostic no-Sentry PR is intentionally marked do not merge. We want to retain Sentry and its database instrumentation in the actual application.

Steps to Reproduce

Three verified Azure experiments

A. Sentry enabled, default SSR configuration — FAIL

Commit:
kt-npm-modules/svelte-adapter-azure-swa@473db3c

Failing Azure job:
https://github.com/kt-npm-modules/svelte-adapter-azure-swa/actions/runs/38960205600/job/117173179946

Result: 39 passed, 1 failed.

The PostgreSQL smoke endpoint returns HTTP 500 instead of 200.

The first Vite SSR stage produces an approximately 801 KB PostgreSQL endpoint bundle containing unresolved CommonJS calls:

__require("pg-types")
__require("pg-protocol")
__require("pgpass")
__require("pg-cloudflare")
__require("pg-connection-string")

These calls survive the adapter's second Rolldown bundling pass and fail during Azure Functions execution.

B. Sentry enabled, ssr.external: ['pg'] — PASS

Commit:
kt-npm-modules/svelte-adapter-azure-swa@7a1f50f

Successful Azure job:
https://github.com/kt-npm-modules/svelte-adapter-azure-swa/actions/runs/38961408425/job/117177863220

Result: 40 passed, including PostgreSQL and both Sentry error-ingestion tests.

Exact comparison of the failing and passing commits:

kt-npm-modules/svelte-adapter-azure-swa@473db3c...7a1f50f

The only functionally relevant change is:

ssr: {
external: ['pg']
}

The first Vite SSR bundle now retains an ordinary import:

import { Client } from "pg";

The second Rolldown pass successfully bundles PostgreSQL and its dependencies.

However, Sentry explicitly warns:

[Sentry] The following packages are marked as external
in your bundler configuration but need to be bundled
for Sentry instrumentation to work: pg.

Remove them from your bundler's "external" configuration,
or use the Sentry Node SDK's runtime instrumentation instead.

Therefore, the workaround fixes deployment but may prevent automatic PostgreSQL instrumentation.

Passing the Sentry error-ingestion tests does not prove that PostgreSQL performance tracing remains functional.

C. Sentry removed, no ssr.external workaround — PASS

Diagnostic draft PR:
kt-npm-modules/svelte-adapter-azure-swa#335

Successful Azure job:
https://github.com/kt-npm-modules/svelte-adapter-azure-swa/actions/runs/38966384532/job/117194085562

Result: 38 passed, including PostgreSQL.

This experiment completely removes Sentry SDK dependencies, its Vite plugin, hooks, server instrumentation, tracing configuration, and Sentry-specific tests.

The adapter and PostgreSQL smoke endpoint remain unchanged. No ssr.external: ['pg'] workaround is present.

The first Vite SSR PostgreSQL endpoint is now approximately 0.20 KB, and the generated Azure Function works correctly.

This is a broader Sentry-removal experiment, not a Vite-plugin-only isolation. It establishes that the failure disappears without Sentry, but does not identify the exact responsible hook.

Expected Result

Default SvelteKit App config, default Sentry config -> pg* are bundled -> deployment to SWA works

Actual Result

Default SvelteKit App config, default Sentry config -> pg* are NOT bundled -> deployment to SWA FAILS

Additional Context

No response

Priority

No response

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    BugSvelteKitWaiting for: Product Owner

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions