Sourcemaps are uploaded but not used

[poskadesign]

Environment

Running a self-hosted version of Sentry. Deploying a static React app (Vite builder, Vercel for deployment)

"@sentry/tracing": "^7.114.0",
"@sentry/vite-plugin": "^2.22.6",
...
"vite": "^5.4.10"

vite.config.ts

defineConfig({
        plugins: [sentryVitePlugin({
            org: 'myproject',
            project: 'internal',
            telemetry: false,
            sourcemaps: {
                assets: './dist/**',
                filesToDeleteAfterUpload: ['./**/*.js.map'],
            },
            release: {
                name: process.env.PUB_RELEASE,
            },
            authToken: '...',
        })],
        build: { sourcemap: true }
}

1. I've made sure the build is a production build.
2. The release has a defined name.
3. I've made sure the files (both minified .js and .js,map) are uploaded by going to the admin panel.
4. The source maps work in the browser.5. I have completed this checklist to no avail https://docs.sentry.io/platforms/javascript/sourcemaps/troubleshooting_js

Steps to Reproduce

After a deployment, if the sourcemaps are exposed on the server, Sentry picks them up and uses them in Issues. But once I use filesToDeleteAfterUpload to remove them, it stops resolving even though they are successfully uploaded.

Expected Result

Sourcemaps are used to resolve stack traces in the Issues tab.

Actual Result

Issues tab still shows the minified version.

Can you please help me debug this? I've sat for several days on this and can't sort it out.

[lforst]

Hi, can you check the logs of your self-hosted symbolicator service when you set filesToDeleteAfterUpload? Thanks!

[poskadesign]

Hey. The logs look like this

...
2025-01-09T23:55:01.758582399Z  INFO symbolicator_service::caching::cleanup: Cleaning up `ppdb_caches` complete
2025-01-09T23:55:01.758584449Z  INFO symbolicator_service::caching::cleanup: Retained 0 directories and 0 files, totaling 0 bytes
2025-01-09T23:55:01.758586159Z  INFO symbolicator_service::caching::cleanup: Removed 0 directories and 0 files, totaling 0 bytes
2025-01-09T23:55:01.758587819Z  INFO symbolicator_service::caching::cleanup: Cleaning up `object_meta` cache
2025-01-09T23:55:01.758681928Z  INFO symbolicator_service::caching::cleanup: Cleaning up `object_meta` complete
2025-01-09T23:55:01.758683928Z  INFO symbolicator_service::caching::cleanup: Retained 0 directories and 0 files, totaling 0 bytes
2025-01-09T23:55:01.758685697Z  INFO symbolicator_service::caching::cleanup: Removed 0 directories and 0 files, totaling 0 bytes
2025-01-09T23:55:01.758687468Z  INFO symbolicator_service::caching::cleanup: Cleaning up `sourcefiles` cache
2025-01-09T23:55:01.759912931Z  INFO symbolicator_service::caching::cleanup: Cleaning up `sourcefiles` complete
2025-01-09T23:55:01.759917701Z  INFO symbolicator_service::caching::cleanup: Retained 0 directories and 0 files, totaling 0 bytes
2025-01-09T23:55:01.759919971Z  INFO symbolicator_service::caching::cleanup: Removed 5 directories and 2 files, totaling 2439878 bytes
2025-01-09T23:55:01.759922011Z  INFO symbolicator_service::caching::cleanup: Cleaning up `auxdifs` cache
2025-01-09T23:55:01.7600266Z  INFO symbolicator_service::caching::cleanup: Cleaning up `auxdifs` complete
2025-01-09T23:55:01.76002898Z  INFO symbolicator_service::caching::cleanup: Retained 0 directories and 0 files, totaling 0 bytes
2025-01-09T23:55:01.76003085Z  INFO symbolicator_service::caching::cleanup: Removed 0 directories and 0 files, totaling 0 bytes
2025-01-09T23:55:01.76003265Z  INFO symbolicator_service::caching::cleanup: Cleaning up `objects` cache
2025-01-09T23:55:01.760127909Z  INFO symbolicator_service::caching::cleanup: Cleaning up `objects` complete
2025-01-09T23:55:01.760129938Z  INFO symbolicator_service::caching::cleanup: Retained 0 directories and 0 files, totaling 0 bytes
2025-01-09T23:55:01.760131698Z  INFO symbolicator_service::caching::cleanup: Removed 0 directories and 0 files, totaling 0 bytes
2025-01-10T23:55:01.468669282Z  INFO symbolicator_service::caching::cleanup: Cleaning up `object_meta` cache
2025-01-10T23:55:01.468720932Z  INFO symbolicator_service::caching::cleanup: Cleaning up `object_meta` complete
2025-01-10T23:55:01.468723042Z  INFO symbolicator_service::caching::cleanup: Retained 0 directories and 0 files, totaling 0 bytes
2025-01-10T23:55:01.468725092Z  INFO symbolicator_service::caching::cleanup: Removed 0 directories and 0 files, totaling 0 bytes
...

I didn't see any error messages or warnings.

[aschmitz]

I'm experiencing what appears likely to be the same issue: self-hosted Sentry (24.12.1), @sentry/vite-plugin (2.23.0) that says the source maps are uploaded successfully, Sentry shows uploaded source maps in the project settings (with the upload ID and debug IDs reported by the Vite plugin, and that correspond to the debug IDs that got baked into the source files), but it isn't making connections when the issues are reported by the Sentry JS plugin (7.120.3).

I haven't dug in to see exactly how they're supposed to be correlated on the server side, so a few observations of things that don't quite line up:

1. The web interface's "Source Maps Loaded" section seems to imply that the JavaScript file hasn't been identified: (index-DffsctBF.js is our main application's JS, there is a separate chunk that is split out because it is rarely needed)

   

   If I click "View", I get a debug ID that matches what has been uploaded:

   

   But clicking "Open in Settings" sends me to the "Debug Files" part of the project's settings (where no source maps exist), not the "Source Maps" section (which contains the uploaded source maps). I assume this is an errant link in the web interface, rather than an indication that source maps should be processed into debug files somehow, but I'll highlight it just in case. The relevant source map upload:

   

   As you can see, the matching debug ID is shown on both the Sentry issue and the source map upload, so I would have expected this to be sufficient. However, the artifact file names do not match what Vite generated (index-DffsctBF.js), though it does seem to at least have had that reference, as the minified version is listed with "Sourcemap Reference: index-DffsctBF.js.map". My best guess is that the mismatched names are the cause of Sentry not loading the source maps.

2. With debug enabled, these are the logs from sentry-vite-plugin when I delete the source files on Sentry and re-build (notably the source files seem to remain somehow on the server, though I had deleted them in the project's settings page - I don't think it's related to this problem, but we also build and upload a separate copy on an ARM platform - Sentry groups these together, so they may be the same output):

   ERROR  [sentry-vite-plugin] Debug: No sourcemaps.assets option provided, falling back to uploading detected build artifacts.
   
   
   ERROR  [sentry-vite-plugin] Debug: Could not determine debug ID from bundle. This can happen if you did not clean your output folder before installing the Sentry plugin. File will not be source mapped: [a file not in index.js]
   
   
   ERROR  [sentry-vite-plugin] Debug: Could not determine debug ID from bundle. This can happen if you did not clean your output folder before installing the Sentry plugin. File will not be source mapped: [a file not in index.js]
   
   > Found 4 files
   > Analyzing 4 sources
   > Adding source map references
   
   [Vite lists files and sizes]
   
   > Bundled 4 files for upload
   > Bundle ID: 47c5738a-daec-5009-8e2d-bc212695db7a
   > Nothing to upload, all files are on the server
   > File upload complete (processing pending on server)
   > Organization: [redacted]
   > Project: [redacted]
   > Release: b760b869
   > Dist: x64
   > Upload type: artifact bundle
   
   Source Map Upload Report
     Scripts
       ~/8929df9b-c484-47da-bf7a-ee5ae3a79759-0.js (sourcemap at [redacted]-DJjj56ex.js.map, debug id 8929df9b-c484-47da-bf7a-ee5ae3a79759)
       ~/a10a0fb9-f9c5-40f6-b7d5-7d2a1a4c3ac1-1.js (sourcemap at index-DffsctBF.js.map, debug id a10a0fb9-f9c5-40f6-b7d5-7d2a1a4c3ac1)
     Source Maps
       ~/8929df9b-c484-47da-bf7a-ee5ae3a79759-0.js.map (debug id 8929df9b-c484-47da-bf7a-ee5ae3a79759)
       ~/a10a0fb9-f9c5-40f6-b7d5-7d2a1a4c3ac1-1.js.map (debug id a10a0fb9-f9c5-40f6-b7d5-7d2a1a4c3ac1)
   
   ERROR  [sentry-vite-plugin] Info: Successfully uploaded source maps to Sentry
   

   Once again this seems to be giving script and source map filenames that don't reflect the actual file names in practice. That's my best guess as to the cause of the issue, but again, I don't know how source maps are identified on the server side, so it's possible they're irrelevant.

You may have noticed our source maps are fairly large, so even though the files are accessible to Sentry, it doesn't seem to pull them down, so I can't quite confirm the same symptoms that @poskadesign is seeing, though the issue feels very similar. (I believe that change in Sentry happened years ago, which is why we push source maps directly.)

Despite commenting on this issue today, this is not necessarily a particularly new issue for us: I don't know if we've ever had working source maps since we switched to Vite several months ago, I just got time this week to investigate, update everything to the latest versions, and try to resolve the problem. (I also don't know where the issue lies: it could be the plugin not uploading correctly, or it could be the server not correlating source maps and debug IDs.)

[lforst]

@aschmitz you have a dist set on the upload. Can you confirm that your Sentry.init() has the same exact dist? Also, in the event, there should be a button "unminify code" - what does it say when you click it?

[lforst]

Also please share screenshots and event payloads of the events if you're able to!