-
Notifications
You must be signed in to change notification settings - Fork 536
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
Conversation
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.
Code Coverage Summary
↑ packages.runtime.container-runtime.src:
Line Coverage Change: 0.02% Branch Coverage Change: No change
Metric Name | Baseline coverage | PR coverage | Coverage Diff |
---|---|---|---|
Branch Coverage | 92.90% | 92.90% | → No change |
Line Coverage | 94.53% | 94.55% | ↑ 0.02% |
Baseline commit: 952e805
Baseline build: 306581
Happy Coding!!
Code coverage comparison check passed!!
⯆ @fluid-example/bundle-size-tests: -347 Bytes
Baseline commit: 952e805 |
// (undocumented) | ||
ensureNoDataModelChanges<T>(callback: () => T): T; |
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.
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 a ensureNoDataModelChanges
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 in 2.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.
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.
@Josmithr, are you also okay with this exception? Latest version has this removed per @jatgarg's suggestion to go the exception route.
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. 🤷♂️
packages/runtime/test-runtime-utils/src/mocksDataStoreContext.ts
Outdated
Show resolved
Hide resolved
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.
Be sure to add a changeset for the removals and if we go with deprecation for the mock, then a deprecation note for it.
packages/runtime/test-runtime-utils/src/mocksDataStoreContext.ts
Outdated
Show resolved
Hide resolved
// (undocumented) | ||
ensureNoDataModelChanges<T>(callback: () => T): T; |
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.
packages/runtime/test-runtime-utils/src/mocksDataStoreContext.ts
Outdated
Show resolved
Hide resolved
I think PR description should be updated. It seems to reference past things rather than describe the current change. Probably should be similar to the changeset content. |
@MarioJGMsoft Since @jason-ha suggested we can remove the test runtime utils one too in this PR, lets remove that as well. Also update the changeset accordingly. |
🔗 No broken links found! ✅ Your attention to detail is admirable. linkcheck output
|
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.
Docs changes look good! Thanks!
Fixes: AB#2309
Description
In light of Remove ability to reject reentrant ops (#20621) · microsoft/FluidFramework@c9d1562 (github.com), updating this to be about finishing the removal of ensureNoDataModelChanges.
The following uses of ensureNoDataModelChanges will be removed:
packages\runtime\container-runtime\src\channelCollection.ts:
packages\runtime\container-runtime\src\dataStoreContext.ts:
packages\runtime\runtime-definitions\src\dataStoreContext.ts:
packages\runtime\test-runtime-utils\src\mocksDataStoreContext.ts: