EMC Perps: propagate Phoenix TWAP warnings through the tree to Perpetual Contracts #103

New Issue

2026-10-26T06:03:17+01:00

minimons commented

2026-10-26 06:03:17 +01:00

Problem

EMC currently attaches Phoenix TWAP information only to an existing nonzero position with matching market metadata. A TWAP that cannot be matched disappears from the overview, even if it has already executed trades and still has outstanding child orders. A blank TWAP column can therefore misleadingly suggest that no relevant order exists.

Observed on 2026-10-26: Phoenix returned one TWAP with assetId = 97, 34 of 346 child orders executed and 312 remaining. Asset 97 was absent from the current market metadata. Phoenix's website counted the order but displayed Unable to load TWAP orders. and TWAP unavailable. Its published client code treats unresolved TWAP market identity as an error and can block new TWAPs on the same Cross account. This suggests an unresolved or obsolete market reference; the reason for the missing market and the order's execution status have not been confirmed.

Make this condition visible so the owner can investigate outstanding orders affecting Evelyn's accounts.

Required behavior

Show a small amber/orange warning triangle with an exclamation mark, similar to the owner's supplied example, together with a short readable description in the existing TWAP column. Do not rely on color or the icon alone.
Put the warning on the specific position row when the TWAP can be reliably associated with that position and its display has a known problem.
If it cannot be associated with a position, put the warning on the owning Cross group. For example: ⚠ TWAP market unavailable or ⚠ Unmatched TWAP. Preserve wallet, trader PDA and subaccount identity; never attach an order to a different account merely because the symbol or index resembles another one.
Keep the real Cross group and its Phoenix parent visible while such a warning exists, including when the account has no current positions. Do not create a synthetic position or invent balances or valuation totals to represent the warning.
If several orders need attention on the same group, show a compact count and include the individual reasons in the tooltip. Each underlying order counts once in each group summary; inherited warnings are not additional orders.
Continue showing ordinary matched TWAP progress bars as before. Keep the Risk column's margin/liquidation assessment independent of this order warning.

Warning propagation through the tree

A warning must be visible both at its source row and on every ancestor, all the way to the Perpetual Contracts root. Inherited indicators use the same small warning icon and a short summary in the TWAP column.
For a warning attached to a Cross position, the path is position → Cross → Phoenix → wallet → Perpetual Contracts. An unmatched order starts on Cross → Phoenix → wallet → Perpetual Contracts. For an isolated position, follow its actual ancestors: position → Phoenix → wallet → Perpetual Contracts; do not invent a Cross parent.
Propagation and counts must be independent of expansion state. Collapsing Cross, Phoenix or a wallet must leave the warning visible on its visible ancestors and the root, so a hidden descendant cannot hide the problem.
Aggregate distinct underlying orders, not warning-bearing child rows. For example, one position warning inherited through five levels still contributes one warning to the root. Root and other group tooltips must identify the affected wallet/account/position and reason without presenting an inherited warning as a new order.
When a successful observation resolves a warning, remove it from its source and all ancestor summaries. Other unresolved warnings must remain. Retained/stale qualifications and original observation times must also be preserved in inherited summaries; propagation must not make old data look fresh.

Tooltip and data handling

Explain the observed reason, such as missing market metadata or no matching open position. Do not assert that the market was delisted, the order was cancelled, or execution has stopped without supporting data.
Include the TWAP account address, asset ID, subaccount, executed/total and remaining child counts, and the original observation time where available. Use raw lots or unknown values when market metadata is missing; do not invent a symbol, token quantity conversion, USD value or execution estimate.
Preserve valid unmatched TWAP information through the Phoenix adapter and Perps snapshot instead of dropping it during position matching. Missing metadata for an otherwise valid order must be representable as a warning without discarding healthy positions and account risk. Keep identity and malformed-response validation intact.
TWAP discovery must also cover existing accounts without held positions; the current position-dependent TWAP read must not prevent detection of the condition above.
Preserve the existing rule from #101: a TWAP with baseLotsFilled = 0 remains invisible everywhere, including warnings and warning counts. The motivating order has already had fills. Orders with no remaining children must not be treated as outstanding unmatched orders.
A later successful observation that resolves or removes the order must update or clear the warning. On lookup failure, preserve the last successful information and timestamp with the existing retained/stale indication; failure must not silently clear the warning or prove that the order has finished.

Scope and verification

Use the project's OpenSpec workflow for implementation.
Keep this read-only and within the existing refresh model, request pacing, timeouts and rate-limit handling. No cancellation, order creation, wallet signing, streaming or general notification system is part of this issue.
Verify the observed missing-market case, a filled TWAP without an open position, an account with no positions, multiple warnings, correct account placement, ordinary matched TWAPs, hidden zero-fill orders, completed orders, recovery, and retained data after failed reads. Verify propagation through every ancestor to Perpetual Contracts with expanded and collapsed branches, distinct-order counts across multiple wallets, and clearing one warning while others remain.
Update relevant repository documentation and r35157_docs where behavior changes, removing obsolete claims about discarded unmatched orders, position-dependent discovery or always-empty group TWAP cells. Add only documentation that explains actual behavior or limitations.
Do not commit or push the implementation.

Related: #101 (TWAP display), #100 (Cross account groups), #102 (independent Risk presentation).

Creating this issue records the task; implementation requires a separate request.

## Problem EMC currently attaches Phoenix TWAP information only to an existing nonzero position with matching market metadata. A TWAP that cannot be matched disappears from the overview, even if it has already executed trades and still has outstanding child orders. A blank TWAP column can therefore misleadingly suggest that no relevant order exists. Observed on 2026-10-26: Phoenix returned one TWAP with `assetId = 97`, 34 of 346 child orders executed and 312 remaining. Asset 97 was absent from the current market metadata. Phoenix's website counted the order but displayed `Unable to load TWAP orders.` and `TWAP unavailable`. Its published client code treats unresolved TWAP market identity as an error and can block new TWAPs on the same Cross account. This suggests an unresolved or obsolete market reference; the reason for the missing market and the order's execution status have not been confirmed. Make this condition visible so the owner can investigate outstanding orders affecting Evelyn's accounts. ## Required behavior - Show a small amber/orange warning triangle with an exclamation mark, similar to the owner's supplied example, together with a short readable description in the existing **TWAP** column. Do not rely on color or the icon alone. - Put the warning on the specific position row when the TWAP can be reliably associated with that position and its display has a known problem. - If it cannot be associated with a position, put the warning on the owning **Cross** group. For example: `⚠ TWAP market unavailable` or `⚠ Unmatched TWAP`. Preserve wallet, trader PDA and subaccount identity; never attach an order to a different account merely because the symbol or index resembles another one. - Keep the real Cross group and its Phoenix parent visible while such a warning exists, including when the account has no current positions. Do not create a synthetic position or invent balances or valuation totals to represent the warning. - If several orders need attention on the same group, show a compact count and include the individual reasons in the tooltip. Each underlying order counts once in each group summary; inherited warnings are not additional orders. - Continue showing ordinary matched TWAP progress bars as before. Keep the Risk column's margin/liquidation assessment independent of this order warning. ## Warning propagation through the tree - A warning must be visible both at its source row and on **every ancestor**, all the way to the **Perpetual Contracts** root. Inherited indicators use the same small warning icon and a short summary in the TWAP column. - For a warning attached to a Cross position, the path is **position → Cross → Phoenix → wallet → Perpetual Contracts**. An unmatched order starts on **Cross → Phoenix → wallet → Perpetual Contracts**. For an isolated position, follow its actual ancestors: **position → Phoenix → wallet → Perpetual Contracts**; do not invent a Cross parent. - Propagation and counts must be independent of expansion state. Collapsing Cross, Phoenix or a wallet must leave the warning visible on its visible ancestors and the root, so a hidden descendant cannot hide the problem. - Aggregate distinct underlying orders, not warning-bearing child rows. For example, one position warning inherited through five levels still contributes **one** warning to the root. Root and other group tooltips must identify the affected wallet/account/position and reason without presenting an inherited warning as a new order. - When a successful observation resolves a warning, remove it from its source and all ancestor summaries. Other unresolved warnings must remain. Retained/stale qualifications and original observation times must also be preserved in inherited summaries; propagation must not make old data look fresh. ## Tooltip and data handling - Explain the observed reason, such as missing market metadata or no matching open position. Do not assert that the market was delisted, the order was cancelled, or execution has stopped without supporting data. - Include the TWAP account address, asset ID, subaccount, executed/total and remaining child counts, and the original observation time where available. Use raw lots or unknown values when market metadata is missing; do not invent a symbol, token quantity conversion, USD value or execution estimate. - Preserve valid unmatched TWAP information through the Phoenix adapter and Perps snapshot instead of dropping it during position matching. Missing metadata for an otherwise valid order must be representable as a warning without discarding healthy positions and account risk. Keep identity and malformed-response validation intact. - TWAP discovery must also cover existing accounts without held positions; the current position-dependent TWAP read must not prevent detection of the condition above. - Preserve the existing rule from #101: **a TWAP with `baseLotsFilled = 0` remains invisible everywhere**, including warnings and warning counts. The motivating order has already had fills. Orders with no remaining children must not be treated as outstanding unmatched orders. - A later successful observation that resolves or removes the order must update or clear the warning. On lookup failure, preserve the last successful information and timestamp with the existing retained/stale indication; failure must not silently clear the warning or prove that the order has finished. ## Scope and verification - Use the project's OpenSpec workflow for implementation. - Keep this read-only and within the existing refresh model, request pacing, timeouts and rate-limit handling. No cancellation, order creation, wallet signing, streaming or general notification system is part of this issue. - Verify the observed missing-market case, a filled TWAP without an open position, an account with no positions, multiple warnings, correct account placement, ordinary matched TWAPs, hidden zero-fill orders, completed orders, recovery, and retained data after failed reads. Verify propagation through every ancestor to Perpetual Contracts with expanded and collapsed branches, distinct-order counts across multiple wallets, and clearing one warning while others remain. - Update relevant repository documentation and `r35157_docs` where behavior changes, removing obsolete claims about discarded unmatched orders, position-dependent discovery or always-empty group TWAP cells. Add only documentation that explains actual behavior or limitations. - Do not commit or push the implementation. Related: #101 (TWAP display), #100 (Cross account groups), #102 (independent Risk presentation). Creating this issue records the task; implementation requires a separate request.

minimons changed title from ~~EMC Perps: warn about unresolved Phoenix TWAP orders on positions or Cross groups~~ to EMC Perps: propagate Phoenix TWAP warnings through the tree to Perpetual Contracts

2026-10-26 06:04:33 +01:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: r35157/com_r35157_nenjim-hubd-impl_ref#103