Offline sourcemaps not used

Hello!

I’m running an on-premise sentry server in docker container (Sentry 8.10.0). We have a webapp built in webpack which in the end has a bundle-[hash].min.js and a bundle-[hash].min.js.map file. I created a new release with sentry-cli:

sentry-cli releases new a3494cd0a6043b80388e4521165b77acd0bdb5e5

and then uploaded assets:

sentry-cli releases files a3494cd0a6043b80388e4521165b77acd0bdb5e5 upload-sourcemaps dist/

It uploads 2 files:

  • ~/assets/bundle-05ed754f62e885e7b062.min.js
  • ~/assets/bundle-05ed754f62e885e7b062.min.js.map

When deploying the project only the JS file is uploaded since we can not publish the sourcemap. JS file is publicly accessible at https://example.com/assets/bundle-05ed754f62e885e7b062.min.js
On the web-interface the new release appears and artifacts are visible too.

In the HTML raven is initialized like this:

Raven.config('https://571be8ea728c416a955775e5bdb90545@sentry.****.hu/2', { release: "a3494cd0a6043b80388e4521165b77acd0bdb5e5", environment: "staging" } ).install()

After receiving an error Sentry displays stack trace like this:

And for some reason it wants to download the sourcemap:

Sourcemap is referenced in JS code like this:
//# sourceMappingURL=bundle-05ed754f62e885e7b062.min.js.map

When source map was uploaded previously(for testing) Sentry was able to show the sourcemapped stack trace.(probably it downloaded it but it means sourcemapping works)

I even tried to upload sourcemaps with url-prefixes like this:

Results were same, no sourcemapped stack traces :frowning:
$ sentry-cli releases list gives me:
screen shot 2016-11-29 at 18 43 14

Where I don’t know what “[unreleased]” means… Maybe that’s the problem

Could you please help me find out the solution?
Thanks in advance!

1 Like

The release name created via the API doesn’t match the release name specified in the client (according to your screenshots). Is that intentional?

Sorry for late response but after 3 days of waiting I even forgot about this forum… I solved the issue by inspecting debug logs of sentry and I found out that I was not mounting the volume where uploaded files are stored in worker containers and they got the task to process those sourcemaps but they couldnt find them. So pay attention to run workers with the same docker configurations/environment/plugins as the master. Maybe docker readme should be more precise about that.

2 Likes

@psychoo118 Thanks for sharing this. I think my team is running into the same thing. Curious, what was the volume that you ended up mounting?

I agree. This would be helpful to include it in the docker sentry readme.

In the end I created a data container which has the volume mounted. Then the main and worker containers of sentry reference it in the “volumes_from” key in my docker-compose file:

   sentry-data:
     image: some.registry.com/repo/docker-sentry
     volumes:
     - /some/path/to/persistent/store/sentry:/var/lib/sentry/files:Z
     command: /bin/true

  sentry:
    image: some.registry.com/repo/docker-sentry
    restart: always
    networks:
        default:
          aliases:
          - sentry
    depends_on:
    - sentry-redis
    - sentry-postgres
    volumes_from:
    - sentry-data
    env_file: .env

  worker-1:
    image: some.registry.com/repo/docker-sentry
    restart: always
    depends_on:
    - sentry-redis
    - sentry-postgres
    - sentry
    volumes_from:
    - sentry-data
    env_file: .env
    command: "sentry run worker --loglevel DEBUG"
3 Likes

Thanks for sharing! Will give this a try and see if it fixes the issue I’m running into :slight_smile:

1 Like

Oh god. That should be highlighted into the documentation.

Sourcemaps haven’t been working for months due to that on our server :sweat_smile:!

Thanks for sharing your solution!

1 Like