Sentry-javascript: Unset tags

[cssetian]

Tags can be set using scope.setTag and scope.setTags but there is only the ability to remove all tags with scope.clear. With SPA's where context changes greatly, it would be beneficial to be able to remove tags by tag name from the given scope

[jeremywiebe]

Chiming in. As I read the code, you can't unset tags by passing undefined or an empty object to setTags() either because the Hub always spreads the existing tags into the new set of tags.

See: https://github.com/getsentry/sentry-javascript/blob/master/packages/hub/src/scope.ts#L126

So a clearTags() method or the ability to send some "sentinal" value to setTags() to clear them would be extremely useful.

As it is, I'm stuck in how to clear the current set of tags from the scope.

[jtomaszewski]

Do you know what happens if you do .setTags({ tagToBeRemoved: undefined })? (Even though TS typedef definition doesn't let undefined in there.)

Is that tag being sent to Sentry and shown in there, even though it has undefined value? Or is it skipped in the Sentry UI completely?

[kamilogorek]

@jtomaszewski undefined is not serializable, so it'll be dropped before it's even sent by JSON.stringify. null is serializable, will be sent through and will be effectively ignored on the server-side, thus skipped in the UI.

[jtomaszewski]

Thanks for the answer. So it means I can unset tags by passing undefined as their value?

Could we update the TS definition for setTag and setTags then, so that it accepts string | undefined as the tag value, not just string ?

[edzis]

In TypeScript I am using Sentry.setTag('mytagname', undefined!) and it is working. But that feels quite wrong. I recognize that for most uscases it is safer for setTag to accept just a string value, but I would like to have an official position from Sentry to help justify this wrong workaround in communication with colleagues.
Update: For undefined! to work with our rather typical eslint setup we have to use // eslint-disable-next-line @typescript-eslint/no-non-null-assertion which adds to the feeling of this being wrong.

[lobsterkatie]

@edzis You're right, we should fix the types. It doesn't solve the OP's problem entirely, but at least codifies that tags _can_ be unset.

I'm about to put up a PR. Will need to get some feedback from the rest of the team, but it seems a reasonable idea to me.