Skip to content

Conversation

@anthony-murphy-agent
Copy link
Contributor

Summary

  • Fix containerObjectMap registration during staging mode to prevent rollback issues
  • When a data store is created during staging mode and then discarded, the containerObjectMap.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

Changes

  • Defer containerObjectMap registration during staging mode by adding to a pending list
  • Flush pending registrations when staging mode exits (both commit and discard)
  • This ensures registration ops are never part of the staged batch and can't be rolled back

Test plan

  • All 200 local-server-stress-tests pass
  • Seed 6 specifically tests this scenario and now passes

🤖 Generated with Claude Code

… 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>
Copy link
Contributor

Copilot AI left a 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>
anthony-murphy-agent and others added 2 commits January 20, 2026 16:48
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>
@anthony-murphy-agent
Copy link
Contributor Author

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

@anthony-murphy
Copy link
Contributor

/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

@anthony-murphy
Copy link
Contributor

/azp run server-gitrest, server-gitssh, server-historian, server-routerlicious

@azure-pipelines
Copy link

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants