Interesting - I assume the feature flag client is doing some caching of the results rather than doing HTTP or something every time? Maybe ValueTask<T> would be a good option for the API (i.e. sync primarily but with async option)... only question is how to introduce it in a back compat way 😅

I considered it originally, my concern was that you probably shouldn't be doing async stuff on your request hot path, so the sync api was meant to encourage you to just do simple stuff or offload to a background service etc if necessary

Yeah, that's probably your best bet

Awesome, Giscus is so much cleaner, and hopefully that script works well for you! 🤞😃

What I don't really understand is if you're redirecting to somewhere on the same origin, then it should be covered by the CSP and not be violating as far as I can tell... But if your Auth is such that you redirect externally, then I'd expect you to hit the issue?

You can see someone having a similar issue with redirects here: community.auth0.com/t/applicatio...

Ah, intriguing! It looks like if you have a redirect from a form submission, you need to have the final location in the CSP too 🤔

github.com/w3c/webappse...

Or put another way, form-action is basically broken in a bunch of scenarios, including PRG pattern🙄

Interesting, I'm out of the country for a couple of weeks but happy to take a closer look when I'm back if you haven't got to the bottom of it 😬 what's the exact error you're getting? 🤔

Any more details? I haven't tried it specifically, but you'll need to allow js sources at a minimum. client-side wasm needs wasm-unsafe-eval too. See learn.microsoft.com/en-us/aspnet... and also the section on frame-ancestors

Tbh, it's not my area, so you'll probably be better of raising a ticket with support 🙂 Not trying to fob you off, just might be quicker for you! 😄

I think the main thing your missing is setting the resources like service.name, deployment.environment.name and service.version using the resource builder, though I can't find any good guidance for your to follow unfortunately

Nothing stands out tbh, RE the metrics, this is the docs logs for the metrics OTLP endpoint, (we're missing a .NET atm) docs.datadoghq.com/opentelemetr...

but the agentless page also says this:

> The Datadog OTLP intake endpoint is in Preview. To request access, contact your account representative

I'm still not quite sure if you want to use the .NET Datadog auto-instrumentation or Datadog.Trace package, or if you want to use pure OTel? This sample shows using the standard `AddOpenTelemetry()` APIs with auto-instrumentation, sending to a Datadog agent: github.com/DataDog/dd-t...