Order -> Arc<Order>

[ZanCorDX]

📝 Summary

To avoid expensive clones, replaced Order with Arc in almost all the code.
Notice that the Arc also enforces immutability, which is something good for the Orders.

✅ I have completed the following steps:

• Run make lint
• Run make test
• Added tests (if applicable)

[claude]

Claude finished @ZanCorDX's task in 1m 53s —— View job

---

Code Review: Order -> Arc

Tasks

• Read CLAUDE.md for repo-specific guidelines
• Analyze the PR changes
• Review code quality and patterns
• Check for potential issues
• Provide feedback

---

Summary

This PR wraps Order in Arc<Order> throughout the codebase to avoid expensive clones. The change is well-executed and the benefits are clear:

1. Performance: Order contains Bundle which has Vec<TransactionSignedEcRecoveredWithBlobs> - each clone previously required deep copying transaction data. With Arc, clones are now just reference count increments (atomic pointer copy).

2. Immutability: As noted in the PR description, Arc enforces immutability at the type level, which is appropriate since orders shouldn't be modified after creation.

Code Quality Assessment

Strengths:

• Consistent pattern applied across all 37 files
• Clean use of Arc::clone(&order) instead of order.clone() which makes the intent explicit
• Added a proper constructor SimulatedOrder::new() rather than exposing the struct fields directly
• Test files updated appropriately

Observations:

1. SimulatedOrder::new() constructor (crates/rbuilder-primitives/src/lib.rs:1020-1030): Good addition. This encapsulates construction and makes future changes easier.

2. Pattern consistency: The PR consistently uses Arc::clone(&x) rather than x.clone() which is the recommended Rust idiom for Arc - it makes it clear that only a reference count increment is happening, not a deep clone.

3. ReplaceableOrderPoolCommand: The changes in orderpool.rs properly use Arc::clone() when forwarding orders to sinks, avoiding unnecessary copies.

Potential Considerations

1. Memory lifetime: With Arc, orders will remain in memory as long as any reference exists. This is typically fine but worth noting - if there are long-lived caches or data structures holding Arc<Order>, they could prevent memory from being reclaimed. From the code review, this appears to be managed correctly through the existing cleanup mechanisms (head_updated, etc.).

2. Thread safety: Arc provides thread-safe reference counting. The Order type is already Send + Sync (from deriving standard traits), so this works correctly with the concurrent builder architecture.

3. No breaking API changes: The changes are internal - external interfaces that take/return Order would need separate consideration, but this PR appears to focus on internal usage.

Minor Notes

• The commit message is clear and concise
• Lint and test checklist items are marked as passing

Verdict

LGTM - This is a well-structured refactoring that should improve performance by eliminating unnecessary deep clones of order data. The implementation is consistent and follows Rust best practices for shared ownership.