How to request a fix backport to 8.0.x?

[swythan]

There's a (one-line) fix I'd like to see backported to 8.0.x. How do I go about it?

The fix in question is:
Issue: #102772
PR: #102960

Without this we're seeing UnobservedTaskException in a lot of our applications when we try to enable TLS switch on our OTEL collector endpoints. Many of those applications have handlers that kill the application when an UnobservedTaskException occurs, so this causes outages.

It seems like a very simple fix. Do I just create a PR against 8.0-staging as described in the "How to service a library" docs?

[EgorBo]

cc @MihaZupan @stephentoub

[huoyaoyuan]

Backport PRs should only be opened by area owners. Customers should open issue/discussion for backport request. You will be asked for business impact and possibility for workaround/upgrading.

[swythan]

OK, cool. I thought that might be the case.

Hopefully this post will be enough to get the conversation started.

[hez2010]

If you want it to be backported, you need to create an issue instead of a discussion, otherwise no one is tracking it.

[MihaZupan]

Many of those applications have handlers that kill the application when an UnobservedTaskException occurs, so this causes outages.

Killing the application on an UnobservedTaskException seems like quite an overreaction, you should consider logging the errors and setting up alerts instead.
There are usually several such bugs we fix in every .NET release, I don't know that this particular one would have an outsized impact.

cc: @dotnet/ncl

[swythan]

It used to be the default, back in the day! 😁

Context:
A number of our apps are involved in unsupervised[1] financial trading so the decision when this code went in was that we didn't want them running with unknown logic errors floating around in the process, and we'd rather they failed outright than did "bad things". We have a moderately-size allowlist for errors which aren't really a problem (and so can be ignored). Weirdly this error appears to be in that allowlist for other reasons, but somehow the logic wasn't quite matching it (maybe the message was subtly different or something).

Anyway: Given that the appetite for a back-port isn't necessarily there for this (and our risk-acceptance profile has changed) we're going to change direction and turn off the "fail on unrecognized error" behaviour and switch to "log and carry-on".

That's only one collection of apps in the firm, but hopefully they're the only ones with this behaviour.

Note that UnobservedTaskException is a really horrible error to get, as (by definition, I think) there is no useful stack trace as to what caused it. I guess once the Task is in a variable it gets hard to write tooling to prove whether or not it is going unobserved.

Thanks, anyway.

[1] Not exactly unsupervised these days, there are various levels of safety (automated & human).

[wfurt]

that fix looks simple enough so I would be supportive. However, I agree with @MihaZupan that killing process on such condition sees strange and we would still need justification for servicing committee to get approval e.g. we cannot do servicing as we please @swythan