setting SentryAspNetCoreOptions on request at runtime

[anwarjaved]

Problem Statement

I have a condition where I have same api in asp.net core for multiple products and I found out the product from domain name on request, is there any way I can set Dsn at runtime so I can use different project in sentry for my products

Solution Brainstorm

No response

┆Issue is synchronized with this Jira Improvement by Unito

[SimonCropp]

DSN is a single setting per app. So there is no easy way to toggle it per products. in theory you implement your own transport, but that is a pretty complex solution to your request.

Have you instead considered assigning a tag to each product?

You can set a tag in a middleware and the assign that tag to a value that represents each of your products

[mattjohnsonpint]

Agree with Simon. This isn't something we can easily support in the SDK. It would also deviate heavily from Sentry's SDKs for other platforms. I suggest you explore tagging as Simon recommended.

Thanks.

[maxkosty]

Would calling Close then re-initializing work for this use case? (assuming it's acceptable to the requester that all scope state is discarded)

I have another customer asking for this.

[jamescrosswell]

Would calling Close then re-initializing work for this use case? (assuming it's acceptable to the requester that all scope state is discarded)

In an ASP.NET Core app, reinitialization should really be done via the IWebHostBuilder.UseSentry extension method since that sets up various things that can only be configured via SentryAspNetCoreOptions. Some of those things have to do with the middleware pipeline so I guess this could work but only if you could find a way to close the Sentry SDK on one request and then reinitialize it upon the next request. There's no easy way to inialize the Sentry SDK to use a different DSN, in the middle of a request.

It'd be good to understand what the use case is for this. What is the customer trying to achieve? There might be another way to do what they want.

[maxkosty]

@jamescrosswell thanks for your insight

Normally we hear this across multiple SDKs from customers with very large, complex applications contributed to by 100s of developers who want to either have better user experience (project dropdown/My Projects instead of filtering tags/saved searches) and/or be able to configure quota management like Spend Allocations or rate limits at finer granularity.

• Python
  • https://github.com/getsentry/sentry-python/discussions/1521
  • https://github.com/getsentry/sentry-python/issues/2012
  • https://github.com/getsentry/sentry-python/issues/1328
  • https://github.com/getsentry/sentry-python/issues/610
  • https://github.com/getsentry/sentry-python/issues/1000
  • (ancient) https://github.com/getsentry/sentry-python/issues/198
• Native:
  • https://github.com/getsentry/sentry-native/issues/612
• .NET:
  • https://github.com/getsentry/sentry-dotnet/issues/1664
• iOS:
  • https://github.com/getsentry/sentry-cocoa/issues/2037
  • https://github.com/getsentry/sentry-cocoa/issues/1232
  • https://github.com/getsentry/sentry-cocoa/issues/1230
  • https://github.com/getsentry/sentry-cocoa/issues/434
  • https://github.com/getsentry/sentry-cocoa/issues/216
  • Related?: https://github.com/getsentry/sentry-cocoa/issues/1812
• React Native
  • https://github.com/getsentry/sentry-react-native/issues/1726
  • related: https://github.com/getsentry/sentry-react-native/issues/132
  • (library): https://github.com/getsentry/sentry-react-native/issues/2857
• Java/Android:
  • https://github.com/getsentry/sentry-java/issues/993
  • https://github.com/getsentry/sentry-java/issues/2736
  • https://github.com/getsentry/sentry-java/issues/620
  • https://github.com/getsentry/sentry-java/issues/512
  • related: https://github.com/getsentry/sentry-java/issues/2668
  • related: https://github.com/getsentry/sentry-java/issues/2576
• Ruby
  • https://github.com/getsentry/sentry-ruby/issues/1572
  • https://github.com/getsentry/sentry-ruby/issues/2132
  • https://github.com/getsentry/sentry-ruby/issues/1292
  • https://github.com/getsentry/sentry-ruby/issues/649
  • https://github.com/getsentry/sentry-ruby/issues/462
  • https://github.com/getsentry/sentry-ruby/issues/455
• PHP:
  • None
• Symphony
  • https://github.com/getsentry/sentry-symfony/issues/521
  • related?: https://github.com/getsentry/sentry-symfony/issues/205
• Go
  • related?: https://github.com/getsentry/sentry-go/issues/155

Plus another ~20 requests for JavaScript where this has been finally solved thanks to Abhi Prasad and Tim Fish.

The customer who's currently requesting this on my end, however, has a different use-case, one which is arguably not in line with Sentry's philosophy. But solution is the same nevertheless and who are we to tell them what to do. Their use case is using their existing pre-Sentry log/crash data pipeline that collects from multiple applications. They want to avoid having to instrument SDK in each app.

Occasionally customers will also ask for a feature like this if want this to monitor a library which I imagine will and should never be supported as it has security and PII risks.

[jamescrosswell]

OK, understood. If this is technically possible to solve (and it sounds like a very big piece of work) I guess it's a priority decision (this vs other stuff we could be solving).

@bitsandfoxes probably a call for you and the good folks at Sentry.

[bitsandfoxes]

It's true that the SDK currently does not provide a proper workflow to support the use-case of multiple DSN or changing the options during runtime. As long as there is a consistent thread or async flow users can work around this limitation by creating and holding their own SentryClient reference (that has its own options) and manually capturing through that. Or bind the client reference to the hub via SentrySdk.BindClient(client); Some features like Release Health that rely on sessions being properly handled might not work tho.