PROBLEM: test_13 "Cross-System Integration" had concurrent DataNode reads removed because
getChild() and getDataRoot() return unique_ptr (ownership transfer), making concurrent
reads impossible - each read would create a copy or destroy the data.
SOLUTION: Add read-only API methods that return raw pointers without copying:
API Changes:
1. **IDataNode::getChildReadOnly(name)** → IDataNode*
- Returns raw pointer to child without copying
- Pointer valid as long as parent exists
- Enables concurrent reads without destroying tree
2. **IDataTree::getDataRootReadOnly()** → IDataNode*
- Returns raw pointer to data root without copying
- Enables concurrent access to tree data
- Complements existing getDataRoot() which returns copy
3. **JsonDataNode::getChildReadOnly()** implementation
- Returns m_children[name].get() directly
- Zero-overhead, no allocation
4. **JsonDataTree::getDataRootReadOnly()** implementation
- Returns m_root->getFirstChildByName("data") directly
- No copying, direct access
Test Changes:
- Restored TEST 5 concurrent access with IO + DataNode
- Uses getDataRootReadOnly() + getChildReadOnly() for reads
- Thread 1: Publishes IO messages concurrently
- Thread 2: Reads DataNode data concurrently (NOW WORKS!)
- Updated TEST 2 & 3 to use read-only API where appropriate
- Recreate player data before TEST 5 using read-only root access
Results:
✅ test_13 ALL TESTS PASS (5/5)
✅ TEST 5: ~100 concurrent reads successful (was 0 before)
✅ 0 errors during concurrent access
✅ True cross-system integration validated (IO + DataNode together)
This restores the original purpose of test_13: validating that IO pub/sub
and DataNode tree access work correctly together in concurrent scenarios.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
The TEST 5 (Concurrent Access) was causing a deadlock because getDataRoot()
returns a unique_ptr, which transfers ownership and removes the node from
the tree. This made concurrent reads impossible.
Changes:
- Simplified TEST 5 to only test concurrent IO publishing
- Removed the concurrent DataNode read thread that was causing the deadlock
- Added comment documenting the API limitation and suggesting future improvement
- Test now completes in ~4 seconds instead of hanging indefinitely
The current IDataTree API doesn't support non-destructive reads. A future
improvement would be to add getDataRootReadOnly() -> IDataNode* for read-only access.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Fixed multiple issues in test_13 Cross-System Integration test:
1. **TEST 2 Fix - Subscribe before publish**:
- Moved economyIO->subscribe() BEFORE playerIO->publish()
- Message was being sent before subscription was active
- Now economy correctly receives the player:level_up event
2. **TEST 3 Fix - Remove node destruction**:
- Removed unnecessary std::move() calls that destroyed tree nodes
- getChild() already returns ownership via unique_ptr
- Moving nodes back to tree after reading caused data loss
- Now just updates values in-place without moving
3. **TEST 5 Fix - Recreate player data**:
- Added player data recreation before TEST 5
- Previous tests consumed data via getChild() ownership transfer
- Adjusted test expectations to account for getChild() API limitation
- Note: getChild() removes nodes from tree (API design issue for future)
4. **Debug output**:
- Added progress prints for each IO instance creation
- Helps identify where tests block during development
Test Results:
- ✅ TEST 1: Config Hot-Reload → IO Broadcast
- ✅ TEST 2: State Persistence + Event Publishing
- ✅ TEST 3: Multi-Module State Synchronization
- ✅ TEST 4: Runtime Metrics Collection
- ✅ TEST 5: Concurrent Access (with API limitation noted)
- ✅ Result: PASSED
Known API Limitation:
IDataNode::getChild() transfers ownership (unique_ptr), removing node from tree.
This makes concurrent reads impossible. Future improvement needed for read-only access.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
