Devone #118
Devone #118
Conversation
Co-authored-by: GPT-5.1-Codex <[email protected]>
Co-authored-by: Codex <[email protected]>
Co-authored-by: Codex <[email protected]>
- Removed the legacy hyperliquid:default alias path so only real venues spin up emitters/websockets; all alias registration and default websocket bootstrap logic is gone, relying entirely on ResolveDefaultAlias. - Updated tests and helpers to source identifiers via storage, ensured default venue fixtures create real primary venues (with flags) so they no longer depend on the sentinel ID, and added a guard to prevent persisting alias data. - Documented the need to call ResolveDefaultAlias in AGENTS.md, refreshed helpers across engine, emitter, filltracker, and storage tests, and made sure cmd/recomma/app.go now persists/boots only concrete venues. Co-authored-by: Codex <[email protected]>
- emitter/emitter.go: inject constraints resolver into the Hyperliquid emitter, snapping create/modify prices to the coin’s tick size (and re-rounded after IOC offsets) before every submission so Hyperliquid no longer rejects IOC orders as “invalid price”. - cmd/recomma/app.go, engine/orderscaler/service.go, tests: wire the new constructor signature through app bootstrap, engine scaler tests, and integration tests so the emitter always receives the shared constraints cache; add TestHyperLiquidEmitterAppliesConstraintsBeforeSubmitting plus supporting test helpers to lock in the behaviour. Co-authored-by: Codex <[email protected]>
- storage/api.go, storage/storage.go, storage/sqlite_test.go: surface the latest Hyperliquid submission (create/modify/cancel) by decoding the stored payloads, log what we return, and verify modify writes so TP resizes don’t disappear. - storage/order_scalers.go, storage/order_scalers_test.go: give scaled-order audits unique IDs (`cloid#stack#timestamp`) and test repeated stack indexes so scaling doesn’t panic on duplicate TP resizes. - engine/engine.go: only skip take-profit actions when both size *and* price already match, and add queue-time logging for visibility into emitted actions. - cmd/recomma/e2e_takeprofit_scaling_test.go: enhance the flaky test with more diagnostics so we can see the last submission when it times out. Co-authored-by: Codex <[email protected]>
- rewired ListLatestTakeProfitStackSizes to select per-leg entries by OrderPosition and consume $.Size, then regenerated the sqlc bindings to match - added TestListTakeProfitStackSizesUsesLegSizes in storage/sqlite_test.go to prove we return the most recent ladder values in order Co-authored-by: Codex <[email protected]>
- rewrite the take-profit stack query to select by OrderPosition and use $.Size, then regenerate the sqlc bindings - clamp the stack index in BuildRequest so each leg maps to its own multiplier slot - cover the regression with TestListTakeProfitStackSizesUsesLegSizes and update the orderscaler stack test Co-authored-by: Codex <[email protected]>
- Record the canceled status in process after emitting TP cancel or fallback cancel-before-recreate so snapshots immediately prune the TP and later reconciliations stay quiet - Add regression test TestReconcileTakeProfitsDropsCancelledTakeProfits reproducing the repeated-cancel bug Co-authored-by: Codex <[email protected]>
…d-test' into fixes/bugs-found-during-test
- add optional hyperliquid status client to emitters and use it to confirm modify calls that return the “missing response.data” error - export hl.OrderQueryResultToWsOrder and reuse it from the emitter fallback and status refresher - update app wiring and emitter tests to cover the new behavior Co-authored-by: Codex <[email protected]>
- merge take_profit_steps from threecommas_deals payload into ListTakeProfitStackSizes so we can build multi-leg stacks before all botevents arrive - teach orderscaler to log partial stacks instead of failing silently - extend the incomplete-stack regression test to assert the returned leg Co-authored-by: Codex <[email protected]>
- treat any Hyperliquid status ending in “canceled/cancelled” as terminal so filltracker drops reduce-only cancels immediately - ensure orderState zeroes remaining qty on these statuses and snapshot logic sees the TP as missing - extend the stale submission regression to exercise the reduceOnlyCanceled path Co-authored-by: Codex <[email protected]>
- treat Hyperliquid’s “Cannot modify canceled or filled order” error as a terminal success so emitters stop requeuing dead work - keep logging and persistence intact so regen/restarts see the final modify attempt Co-authored-by: Codex <[email protected]>
…ails Co-authored-by: Codex <[email protected]>
Co-authored-by: Codex <[email protected]>
- add regression coverage to ensure cancelled TPs retain real filled qty - stop markOrderCancelled from inflating filledQty so deal recompute stays accurate Co-authored-by: Codex <[email protected]>
Prevent HyperLiquid emitters without a constraints cache from panicking during modify submissions by short-circuiting price quantization when the resolver is absent. Co-authored-by: Codex <[email protected]>
Fixes/bugs found during test
Ensure modify emissions are preserved while replaying create requests for missing venues by adding a dedicated regression test. Co-authored-by: Your Name <[email protected]>
Ensure modify emissions continue for existing venues while replaying creates for missing assignments. Co-authored-by: Your Name <[email protected]>
…fix-modify-emissions test(engine): add replay modify regression
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ 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".
emitter/emitter.go
Outdated
| logger.Info("modify skipped because order already filled or canceled", slog.String("cloid", cloid)) | ||
| err = nil | ||
| } else { | ||
| logger.Warn("could not modify order", slog.String("error", err.Error()), slog.Any("action", req)) | ||
| return nil, fmt.Errorf("could not modify order: %w", err) |
There was a problem hiding this comment.
Avoid recording modify submissions after filled rejection
When Hyperliquid responds "cannot modify canceled or filled order" we zero the error and fall through, so the subsequent append still records the modify payload and the function returns nil. That means a rejected resize is persisted as if it succeeded, leaving storage with a phantom modify and callers believing the order was updated, which can block retries or reconciliation while Hyperliquid keeps the old size/price. This is hit whenever a modify is issued for an order that was already filled or canceled.
Useful? React with 👍 / 👎.
Co-authored-by: Your Name <[email protected]>
Avoid storing modify requests rejected for filled or canceled orders. Co-authored-by: Your Name <[email protected]>
…dle-order-errors fix: skip persisting rejected modifies
…-handling Add regression test for terminal modify persistence
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ 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".
engine/orderscaler/service.go
Outdated
| stackIndex := evt.OrderPosition | ||
| if stackIndex < 0 { | ||
| stackIndex = 0 | ||
| } | ||
| stackSize := evt.OrderSize |
There was a problem hiding this comment.
Convert order_position to zero-based before scaling TP legs
Multi-leg take-profit events are documented as 1-indexed (OrderPosition in internal/api/ops.gen.go line 584), but BuildRequest now treats the value as zero-based. For a two-leg ladder, the first leg arrives with order_position=1 and order_size=2, yet this code sets stackIndex to 1 rather than 0, while the second leg is clamped to the same index. Both legs therefore use the second stack slot and the first leg’s size/price are never applied, emitting wrongly sized/colliding Hyperliquid orders for every multi-target deal. The index should still be decremented to align with the 1-based input.
Useful? React with 👍 / 👎.
Ensure order_position from bot events is converted from 1-based to zero-based before clamping stack index so multi-leg take-profit legs target the correct stack slot. Co-authored-by: Your Name <[email protected]>
Co-authored-by: Your Name <[email protected]>
Co-authored-by: GPT-5.1-Codex-Max <[email protected]>
Co-authored-by: Your Name <[email protected]>
…servestakeprofitstackratios-fixtur Align take profit positions in orderscaler test
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ 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".
|
|
||
| defaultAliasWallet := strings.TrimSpace(defaultVenueWallet) | ||
| if defaultAliasWallet == "" { | ||
| defaultAliasWallet = defaultHyperliquidWallet |
There was a problem hiding this comment.
Remove unused default alias wallet variable
The new defaultAliasWallet local declared in initializeHyperliquidVenues is never read after the default-alias bootstrap block was deleted, so the file no longer compiles—Go rejects unused variables in production code. Any go build or go test of cmd/recomma will fail at compile time before runtime behavior is exercised.
Useful? React with 👍 / 👎.
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ 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".
| result := make(map[int]float64, len(deal.TakeProfitSteps)) | ||
| for idx, step := range deal.TakeProfitSteps { | ||
| pos := idx | ||
| if step.Id != nil && *step.Id >= 0 { | ||
| pos = *step.Id | ||
| } | ||
|
|
||
| size := parseNumericString(nullableString(step.InitialAmount)) | ||
| if size <= 0 && step.AmountPercentage != nil && baseVolume > 0 { | ||
| size = baseVolume * float64(*step.AmountPercentage) / 100.0 | ||
| } | ||
| if size <= 0 { | ||
| continue | ||
| } | ||
| result[pos] = size |
There was a problem hiding this comment.
Normalize TP step ids before rebuilding stack
The fallback that reconstructs take‑profit stacks from deal payloads treats TakeProfitStep.Id as a zero‑based index (pos = *step.Id), but the rest of the stack logic expects zero‑based positions derived from 1‑based 3Commas values (see OrderPosition: pos+1 in the TP tests). When 3Commas sends steps with IDs 1..N, takeProfitStackFromDeal will populate the map starting at key 1, and ListTakeProfitStackSizes immediately stops at missing position 0, returning an empty stack even though the deal carries valid leg sizes. Multi‑leg deals therefore never get their ladder reconstructed from the deal JSON, keeping the scaler blind to additional legs.
Useful? React with 👍 / 👎.
Co-authored-by: Your Name <[email protected]>
…ti-leg-take-profit fix(storage): normalize take-profit step ids
7390c40
into
claude/e2e-test-investigation-013azTCiApSXWkNF8SuhPdLk
No description provided.