-
Notifications
You must be signed in to change notification settings - Fork 562
fix(local-server-stress-tests): defer containerObjectMap registration during staging mode #26257
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
base: main
Are you sure you want to change the base?
Conversation
… during staging mode When a data store is created during staging mode, the containerObjectMap.set() operation was being staged along with other ops. If staging mode was discarded, the set was rolled back, but the data store still existed locally. When the data store was later attached (by storing its handle in a DDS), other clients couldn't find it because it wasn't in containerObjectMap. The fix defers containerObjectMap registration during staging mode by: 1. Adding objects to a pending list instead of writing to containerObjectMap 2. Flushing the pending list when staging mode exits (commit or discard) This ensures registration ops are never part of the staged batch and can't be rolled back. The data store may still be detached when flushed (on discard), but getContainerObjects handles this gracefully by only returning resolvable objects. Co-Authored-By: anthony-murphy <anthony.murphy@microsoft.com> Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
packages/test/local-server-stress-tests/src/stressDataObject.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.
Pull request overview
This PR fixes a bug where data stores created during staging mode couldn't be found by other clients after the staging was discarded and the data store was later attached through a DDS.
Changes:
- Defer containerObjectMap registration during staging mode by adding objects to a pending list
- Flush pending registrations when staging mode exits (for both commit and discard operations)
- Ensure registration operations occur outside the staged batch to prevent rollback
…duplication Addresses review comment by extracting the containerObjectMap registration logic into a reusable helper method. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> Co-Authored-By: anthony-murphy <anthony.murphy@microsoft.com>
packages/test/local-server-stress-tests/src/stressDataObject.ts
Outdated
Show resolved
Hide resolved
Remove the registerToContainerObjectMap helper method and inline the logic directly in both registerLocallyCreatedObject and exitStagingMode, as the helper was small and single-use in each location. Co-Authored-By: anthony-murphy <anthony.murphy@microsoft.com> Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
…ContainerObjectRegistrations Per review feedback: keep the registerToContainerObjectMap helper method, and only remove flushPendingContainerObjectRegistrations by inlining its call directly in exitStagingMode. Co-Authored-By: anthony-murphy <anthony.murphy@microsoft.com> Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
Azure Pipelines commands (copy and post separately, limit of 10 at a time): |
|
/azp run Build - api-markdown-documenter, Build - benchmark-tool, Build - build-common, Build - build-tools, Build - client packages, Build - common-utils, Build - eslint-config-fluid, Build - eslint-plugin-fluid, Build - protocol-definitions, Build - test-tools |
|
/azp run server-gitrest, server-gitssh, server-historian, server-routerlicious |
|
Azure Pipelines could not run because the pipeline triggers exclude this branch/path. |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Summary
Changes
Test plan
🤖 Generated with Claude Code