-
Notifications
You must be signed in to change notification settings - Fork 535
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Notify channel and channel contexts of their used routes. #4764
Notify channel and channel contexts of their used routes. #4764
Conversation
■ @fluidframework/base-host: No change
⯅ @fluid-example/bundle-size-tests: +809 Bytes
Baseline commit: 4e06335 |
@@ -562,6 +585,9 @@ export abstract class FluidDataStoreContext extends TypedEventEmitter<IFluidData | |||
// returned in packagePath(). | |||
Object.freeze(this.pkg); | |||
|
|||
// Update the used routes of the channel in case GC was run before we were realized. | |||
this.updateChannelUsedRoutes(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe the intention is for data store to be able to reason about non-referenced DDSs and be able to purge them.
And I'd guess same for sub-DDS level.
Have you considered the impact of calling it at random times (relative to when summarization / snapshot runs)?
I.e. I'd assume that something like at-mentions data store would not be able to use results of this call if it happens outside of summary processing, as undo/redo could reinsert content that points to same route (in case of at-mentions, it's just a key in DDS - the same key gets reinserted, but deleting it after undo as unused would be incorrect).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As per our discussion offline, it is currently going to be difficult to handle the scenario where data stores start using the result of this call to delete stuff and undo / redo happens. Even if this is tied to summary, it is hard to get this right because of the ordering of the delete op and undo / redo op.
So maybe these data stores should not delete things but only exclude them from search results to begin with.
This change notifies channel contexts of used routes. The contexts don't use these routes to update their state but this puts the code in place for that to eventually happen.
When a data store's used routes are updated, if it is realized, it updates the context's used routes. If it is not realized yet, this is updated when the data store is realized.
Note: This is needed to fix the problem in #4750. I will have a PR for that out soon.