rkargMsft

I started some exploration of this to better understand where events happen but there have been some changes around lifecycles since starting this that will need a bit of rework....

@copilot I choose you!

Looks like the removal was to allow for decisions to be cached and not depend on per-call data to make a decsion. But there are use cases, like above, that...

@ReubenBond What would the scope of caching the filter results? If we have the same set of silos coming in and it's the same type and interface version then something...

For the use case. the built in filters use the current silo's metadata and compare that across other candidate silos to filter down. No per-call data from RequestContext is required...

I guess that even without the RequestContext, there could be arbitrary logic to do the filtering. It could be a random chance that each candidate silo gets filtered out resulting...

Here's an attempt at allowing both types of filters (without and with RequestContext available): https://github.com/dotnet/orleans/pull/9480 But I still think that we may not be able to make the assumption that...

In that case, then we could add the RequestContext back in (use PlacementTarget). Then have some opt-in mechanism (ICacheablePlacementFilterDirector interface) that provides the cache key and indicates that the user...

Here's adding PlacementTarget back https://github.com/dotnet/orleans/pull/9482

I tried to read through the various support policies listed above and ended up getting linked from one to a different one and then mixing up which applied to what....