unhandledException - sticky tag data

[crussell52]

Env

platform: mac-os, linux (appImage)
sdk: 1.0

Description

After configuring tags using configureScope(), obsolete tags (from previous builds) appear in scope during process.unhandledException handling.

Obsolete tags do not go away until userData dir (or probably some specific portion of it) is cleared.

This is observable without the default integrations by inspecting the scope at specific times in app lifecycle.

Repro

This is something that I observed while distilling #195

It requires two builds of the same application... On build 1 the the foo tag is included, on build 2, the bar tag is included instead, but foo is still in the scope output of the unhandledException handler.

const {app} = require('electron');
const Sentry = require('@sentry/electron');

Sentry.init({
    dsn: myDSN,
    debug: true,
    defaultIntegrations: false
});

console.log(app.getPath('userData'));

Sentry.configureScope((scope) => {
    scope.setTag("foo", "foo");  // Run 1 ONLY
    // scope.setTag("bar", "bar"); // Run 2+ ONLY
    console.log('configureScope', scope._tags); // OK!
});

Sentry.withScope(scope => {
    console.log('withScope', scope._tags); // OK !!
});

process.on('uncaughtException', (e) => {
    Sentry.withScope((scope) => {
        console.log('uncaughtException', scope._tags); // still has `foo`  on Run 2+
        app.exit();
    })
});

setTimeout(() => junk(), 10000);

[crussell52]

Also just observed this related behavior... using the same repro app, altering only configureScope():

Run 1

   // configureScope
   scope.setTag("foo", "foo"); 
   scope.setTag("bar", "bar"); 

Run 2:

  // configureScope
   scope.setTag("foo", "foo"); 
   scope.setTag("bar", "bar-run-2"); 

Output from Run 2:

configureScope {} { foo: 'foo', bar: 'bar-run-2' }
withScope {} { foo: 'foo', bar: 'bar-run-2' }
uncaughtException {} { foo: 'foo', bar: 'bar' }

[timfish]

It looks like you're reporting two issues here

• foo still exists on tag scope after setting other tags
• tags are not making it to uncaughtException?

The first one is actually the expected behaviour. As you can see here setTag and setTags don't replace the whole tag object, they merge.

You can stop a tag from appearing in Sentry with:

scope.setTag("foo", undefined);

The second one I'll have to take a look at. If you get a minute, could you you open a PR with a failing e2e test showing this failure? There are already a couple there that do multiple app runs.

[crussell52]

@timfish

Sorry, I don't think I expressed this very well because there seems a couple different problems in this area.

foo still exists on tag scope after setting other tags

Not quite, I understand and expect the merge behavior. But in this case foo still exists in the scope used for unhandledException even if I run a new build of the app that never sets foo.

For that matter, if I set foo to a different value between runs, the more recent value doesn't appear in scope with the unhandledException handler. Note, I'm changing the value in the source, rebuilding, and running again -- but I see no reason that a dynamic value would behave differently.

scope.setTag("foo", undefined);

Doing this DOES affect the scope that prints out during configureScope(). However, the scope that is present in unhandledException is not affected.

I haven't dug too deep into the source, but I think all the symptoms are explained by these observed behaviors:

1. The on-disk scope (userData/scope_v2.json) is always used in the unhandledException handler.
2. The on-disk scope does not update when tag receives a new value if that tag already exists in the on-disk scope.
3. Pre-existing tags are never removed from the on-disk scope (setting to undefined doesn't work because of 2)

[crussell52]

If you get a minute, could you you open a PR with a failing e2e test showing this failure?

Sorry, clear not on what you want me to do.

Any progress on this, in general?

[douglassllc]

This seems like a bug to me. I asked about this same situation to tech support and during a webinar. Neither case did I receive an explanation as to how to resolve this situation. I think the problem is well explained/document here in this issue, so hopeful someone more knowledgeable at Sentry will chime in to offer some assistance.

[HazAT]

This is a bug yes, here is the fix
#242