Reuben Bond

That's fair, @srollinet - I think your approach is doable. It may be too much control for many users who just want to plug in some custom serializer, but it...

We need to extend the functionality which @benjaminpetit implemented in #7416 for Azure to the other providers, including ADO.NET (this issue) and, in doing so, remove the current custom serializer...

There are a couple of ways to think about gRPC support. One is to use gRPC as a transport and that's what Bedrock support could help with since it allows...

@shersh Bedrock helps with the first option: using gRPC as a transport, which I wouldn't recommend pursuing. It does not help with the second option in which grains are exposed...

Bedrock isn't particularly helpful there, but there is a different feature which we added in 2.1 which helps: "Hosted Client". That feature is enabled by default and allows grain calls...

@nkosi23 if we do add something like this (contributions more than welcome), I hope that we keep any additional code generation to an absolute minimum (ideally none): perhaps only including...

If the application is operating without issue, you can consider ignoring it. However, it does typically indicate a low severity issue. For example, it might indicate a long garbage collection...

If you see a lot of warnings, then it's worth investigating by capturing logs and potentially CPU traces. It's fairly common for some thread pool misuse to cause starvation. Eg,...

Sounds like a great idea, I think we could include something like this in a TestKit package. Currently we have the [TestingHost](https://github.com/dotnet/orleans/tree/main/src/Orleans.TestingHost) package, which serves a vaguely similar purpose, so...

How should we address this? Generally speaking, there's no way to know which errors are transient and which are permanent/fatal.