Internal flows corrupt on save/reload when multiple flows exist between same subsystem pair

[rsthornton]

Internal flows corrupt on save/reload when multiple flows exist between same subsystem pair

Summary

When a model contains multiple flows between the same two subsystems (bidirectional or parallel), saving and reloading the model corrupts all but one flow per pair. Corrupted flows render as unclickable floating white text boxes in the center of the SOI.

Reproduction Steps

1. Create or load a model with 2+ subsystems (e.g., Protocol, Mining, Validating)
2. Add multiple internal flows between the same subsystem pair:
   • Flow A: Mining → Protocol
   • Flow B: Protocol → Mining
3. Verify both flows render correctly (they will)
4. Save the model
5. Reload the model
6. Result: Only one flow survives; the other becomes a floating white text box

Expected Behavior

All flows should persist through save/reload cycle regardless of how many flows connect the same subsystem pair.

Actual Behavior

• Only one flow per subsystem pair survives save/reload
• Other flows render as floating white text boxes in center of SOI
• Corrupted flows are unclickable - cannot select or delete via UI
• Only fix is manually editing JSON to remove orphaned flow entries

Test Cases

Reproduced 3 times with different models (created locally during debugging, not in repo):

• bitcoin-4.0.json - 6 manual flows (2 per pair with Protocol) → 3 survived
• bitcoin-4.1.json - Same pattern → Same result
• multiflow.json - Fresh test model → Same result

Reproduction is straightforward with any model containing 2+ subsystems.

Environment

• BERT version: 2.5 (current main)
• OS: macOS
• All tests done with manually-added flows (no LLM generation involved)

Workaround

Limit models to ONE flow per subsystem pair until fixed.

For bidirectional relationships, either:

• Choose dominant flow direction only
• Combine into single "Exchange" flow representing both directions

Investigation Notes

Likely locations in codebase:

• src/data_model/ - Model serialization/deserialization
• Flow storage structure - possible HashMap key collision on (source, sink) pair?
• Save logic may be deduplicating flows with same endpoints

The bug occurs during save/reload cycle, not during flow creation (flows render correctly before save).

Note on Earlier Misdiagnosis

Initial debugging suggested "LLM-generated flows break after ~2" - this was a misdiagnosis. The LLM happened to generate bidirectional flow pairs, which triggered this underlying bug. Pure manual testing (bitcoin-4.0 with zero LLM involvement) confirmed the root cause is multiple flows per pair, not LLM generation.