You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The problem is that in some cases, trying to determine whether retries or refreshes to container cached calls from the container (container calling itself) require retries and refreshes based on FeedRanges that have no knowledge of the container it actually originated from. This is exclusive to CF/P.
Describe the solution you'd like
Include Container resource id on the types derive from FeedRange. Understand the impact of change. Have an exhaustive list of test cases to support this. So when FeedRanges are passed into any container methods, we can determine if that FeedRange exists on that container and perform at least one refresh and retry on the container to check its staleness.
Describe alternatives you've considered
Change feed context core type can include the Container resource id since it currently has the FeedRange, so you can make the correlation there, but other methods on the container that use FeedRange as an argument to a parameter, would need to overload to include the container resource id. Less intrusive approach on the FeedRange type, but more intrusive to other methods. An assessment must be made.
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
The problem is that in some cases, trying to determine whether retries or refreshes to container cached calls from the container (container calling itself) require retries and refreshes based on FeedRanges that have no knowledge of the container it actually originated from. This is exclusive to CF/P.
Describe the solution you'd like
Include Container resource id on the types derive from FeedRange. Understand the impact of change. Have an exhaustive list of test cases to support this. So when FeedRanges are passed into any container methods, we can determine if that FeedRange exists on that container and perform at least one refresh and retry on the container to check its staleness.
Describe alternatives you've considered
Change feed context core type can include the Container resource id since it currently has the FeedRange, so you can make the correlation there, but other methods on the container that use FeedRange as an argument to a parameter, would need to overload to include the container resource id. Less intrusive approach on the FeedRange type, but more intrusive to other methods. An assessment must be made.
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered: