Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Remove back-compat code related to the op reentry checks #22842
Remove back-compat code related to the op reentry checks #22842
Changes from all commits
8e256ba
d036753
c3698df
4de92ce
817aefa
6e52198
310f952
352b303
bffeadd
c22885b
1598800
5a45ae4
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
This technically should have been marked as deprecated before now. To be completely strict we would not remove this from the mock until properly deprecated. This is test-runtime-utils and maybe there is a different contract there. I will let API CR make final call.
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.
Unless there is a reason we have to remove this in this PR and we are confident that none of our partners are using it (beyond just Loop), then I think it would be best to stick to the process and retain this as deprecated for future removal.
I see that we had an internal-facing comment noting it would be removed in 2.0, but our customers would have had no awareness of this, so I think it's worth erring on the side of caution.
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.
So, it seems like "ensureNoDataModelChanges" was deprecated on the interface and now he is removing it from the interface and classes.
Is it wrong to do so? In order to remove it, should it be marked as deprecated on interfaces and all classes implementing that interface?
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.
@jason-ha and @Josmithr Please take a look at this comment when you get time. We need to complete this breaking change PR by next week. Thanks.
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.
Sorry, missed the earlier responses. Yes, strictly speaking any implementation of the interface that declares the same properties should also mark the members as deprecated. There is nothing stopping
MockFluidDataStoreContext
from continuing to expose aensureNoDataModelChanges
member even if the interface it extends plans to remove it from the interface. So, to be explicit, any implementations for which the member is deprecated should be marked so as well.Unless there is an urgent need to remove this, it would probably be better to mark the appropriate implementation members as
@deprecated
and add them to the issue tracking@legacy
breaks we plan to make in2.20
.I don't think there is anything stopping us from removing the deprecated interface member, though.
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 would be okay making an exception for this one since the expected use is for mock to be used in places that would use
ensureNoDataModelChanges
via interface. Technically, we should have deprecated before and should wait, but I would be surprised if there is fallout.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.
@Josmithr, are you also okay with this exception? Latest version has this removed per @jatgarg's suggestion to go the exception route.
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.
@MarioJGMsoft, please make sure you have tested a build with these changes using the FF+Loop integration process. Reply with the build results link. Thanks!
Reference docs: https://eng.ms/docs/experiences-devices/opg/office-shared/fluid-framework/fluid-framework-internal/fluid-framework/docs/dev/monitoring/ff-loop-testing
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 don't have a strong opinion either way. Introducing a break to something with "Mock" in the name seems safer than most alternatives, so I don't see any harm in it. But I do think we should generally try to be consistent with this stuff. 🤷♂️