Fix Multi-Venue Scaled Order Architecture #76
Conversation
This commit fixes three critical bugs in the scaled order system related to multi-venue support: Bug #2: Hard-coded Default Venue in Queries - Remove venue_id filter from ListScaledOrdersByOrderId and ListScaledOrdersByDeal - These queries now return records from all venues instead of just the default Bug #3: Wrong Venue Assignment in InsertScaledOrderAudit - Change InsertScaledOrderAudit to use venue/wallet from the OrderIdentifier parameter - Add fallback to default venue for backward compatibility - Each audit record now correctly reflects the actual submission venue Bug #4: Missing Venue Context in Parameters - Update ScaledOrderAuditParams and RecordScaledOrderParams to use OrderIdentifier - Add Identifier field to orderscaler.Request - Update BuildRequest to accept OrderIdentifier parameter - Change applyScaling to accept OrderIdentifier and scale per-venue - Refactor engine emission loop to scale each venue independently The key architectural change is moving from "scale once, apply to all venues" to "scale per-venue" which ensures each venue gets its own audit record with the correct venue and wallet information. Note: After pulling this commit, run `go generate ./...` to regenerate sqlc code. Fixes #2-4
- Update orderscaler service tests to create OrderIdentifier for BuildRequest - Update storage tests to use Identifier field instead of OrderId - All tests now properly construct multi-venue identifiers
There was a problem hiding this comment.
💡 Codex Review
recomma/filltracker/service.go
Lines 542 to 545 in ed82f06
ListScaledOrdersByOrderId now returns scaled-order audits for every venue because the storage query no longer filters by venue_id. reloadDeal still selects only the last element of that slice (latestScaled) and applies it to every identifier in the deal, so identifiers whose most recent audit belongs to a different venue will pick up the wrong multiplier and size. Consider selecting the audit entry that matches each identifier’s venue or filtering the query per identifier before updating tracker state.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
- Add VenueID and Wallet fields to ScaledOrderAudit struct - Update convertScaledOrder to populate venue fields - Fix filltracker reloadDeal to match scaled orders by identifier's venue - Prevents applying wrong venue's multiplier/size to identifiers This fixes a bug where ListScaledOrdersByOrderId returns audits from all venues but filltracker was only using the last one for all identifiers, causing venue mismatches when different venues have different scaled sizes.
|
@codex review |
|
Codex Review: Didn't find any major issues. You're on a roll. ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
c12d10e
into
codex/extend-cmd/recomma-to-handle-multiple-venues
Updated MULTI_VENUE_BUGS.md to reflect resolved issues: Resolved (PRs #75 and #76): - Bug #1: OrderWork comparability violation - Bug #2-4: Scaled orders multi-venue architecture Remaining issues (renumbered #1-4): - Bug #1: Missing scaled_orders in wallet migration (High) - Bug #2: Take profit reconciliation fan-out (Medium) - Bug #3: Fill tracker memory growth (Medium) - Bug #4: Replay logic edge case (Low) PRs: - #75: Removed pointer fields from Action struct - #76: Fixed multi-venue scaled order handling
Problem Statement
The scaled order system had three critical bugs that broke multi-venue support:
Bug 2: List queries hard-coded the default venue ID, preventing retrieval of scaled orders from other venues
Bug 3: InsertScaledOrderAudit always used the default venue when creating audit records, regardless of which venue the order was actually submitted to
Bug 4: The scaled order audit pipeline only passed orderid.OrderId, which lacks venue context needed to identify which venue an order belongs to in a multi-venue system
Root Cause
Architectural mismatch: Scaling happened once per emission (targeting multiple venues), but audit recording assumed a single default venue without venue context. This caused audit records to only be created for the default venue, making it impossible to query scaled orders for non-default venues.
Solution
Changed from "scale once, apply to all venues" → "scale per-venue" to ensure each venue gets its own scaling operation and audit record with the correct venue/wallet context.
Changes Made
SQL Queries - Removed hard-coded venue_id filters from ListScaledOrdersByOrderId and ListScaledOrdersByDeal so queries return records from all venues
Storage Parameter Structs - Updated ScaledOrderAuditParams and RecordScaledOrderParams to use recomma.OrderIdentifier (contains venue, wallet, order ID) instead of just orderid.OrderId
InsertScaledOrderAudit - Changed to use venue/wallet from the OrderIdentifier parameter instead of always defaulting to defaultHyperliquidVenueID. Added fallback for backward compatibility.
Orderscaler Service - Added Identifier field to Request struct and updated BuildRequest to accept and use OrderIdentifier parameter
Engine Emission Loop - Refactored to scale per-identifier instead of scaling once and applying to all venues. Each venue now gets its own applyScaling() call with proper venue context.
Test Updates - Updated all test files to construct proper OrderIdentifier instances and use the Identifier field in parameter structs