View active and past orders
Customer App can present My Orders for the current signed-in account. Its Orders tab mounts Preorders, Active orders, and Past orders as three separate sections. Their reads, loading, errors, pagination, socket events, and freshness do not settle as one snapshot.
Opening or refreshing My Orders can start multiple private order reads, realtime room/listener work, timers, and remote media requests. A visible card is not a read-only receipt or proof that every section is current.
My Orders entry and three sections
| Section | Intended source state | Important boundary |
|---|---|---|
| Preorders | Orders in the current preorder status class | Can load, fail, paginate, and receive events independently. |
| Active orders | Orders in current in-progress status classes | A status or time estimate can change independently of other card fields. |
| Past orders | Orders in completed or terminal status classes | Historical visibility does not authorize reorder, review, favorite, help, or another action. |
Pull-to-refresh can request all three sections, but it does not make their responses one transaction or one revision. One section can update while another still shows retained, empty, loading, or error state.
Minimal order-card interpretation
For documentation, the safe card model is deliberately minimal:
| Card element | Safe interpretation |
|---|---|
| Business or grouped-order label | Presentation for the returned order/group context; ownership still requires server authorization. |
| Status label | A derived status class at one point in time; it can become stale. |
| Time or estimate | A displayed historical time or current estimate; it is not a completion or delivery guarantee. |
| Card selection | A request to open the separately authorized Order Details or grouped-order surface. |
Current cards can display additional reference, total, favorite, review, or reorder information. Other shared-card contexts can also present unread state. Those values and actions are private or separately effectful and are not reproduced in this guide.
Loading, empty, error, refresh, and pagination
| Observable state | Safe interpretation |
|---|---|
| Section loading | That section has unresolved reads; another section can already be visible. |
| Section empty | The current authorized page returned no matching rows; it does not prove no order exists in another section/page/context. |
| Section error | That section is unresolved; retained cards elsewhere can be stale. |
| More pages available | Additional rows may exist for that section; pagination is not a complete order-history receipt. |
| Refresh completes | One or more requests returned; socket events and other sections can still be ahead or behind. |
| Card moves or disappears | Status filtering, refresh, event, account, or project state changed; no cancellation/refund/deletion inference follows. |
Do not repeatedly refresh or paginate to test whether an order exists or to force status convergence.
Passive reads, sockets, and media
Each section can start an authenticated order read and subscribe to order events. The current page can create overlapping room joins, listeners, reconnect work, and pagination updates. Cards or related tabs can also load remote business, product, gift-card, or other media/data.
A connected channel does not prove missed-event replay, current page membership, one listener per section, or complete room cleanup. Leaving My Orders, logging out, changing account/project, or replacing the current session must stop old reads, listeners, rooms, media, and late callbacks before they update the new context. The pinned paths do not establish that lifecycle completely.
Account, guest, ownership, and freshness
The ordinary list is account-private and requires exact current account, project, session, and order ownership. Guest-created order history and guest-to- account migration use a separate capability and merge contract; a stored or visible guest context is not sufficient authority.
Every list response and realtime event must be bound to the current account, project, session, section, order, and revision. A card's presence, status, time, business label, favorite state, or unread state is not an authorization receipt and can be stale after account/project/session change.
Favorites, help, and card actions
Selecting a card, changing Favorite, Review, or Reorder crosses a separate authorization and settlement boundary. Messages, Help, tracking, checkout, cancellation, refund, and other downstream actions belong to separately authorized destinations. A list card must remain pre-action until the customer explicitly chooses one supported action.
Do not use Favorite, Help, Reorder, Review, or another action to test list freshness. Navigation, a changed icon, a removed row, or a toast does not prove the downstream operation settled.
Order subtypes and grouped handoffs
A returned card can represent an ordinary order, grouped orders, a gift-card order, a custom-order display, a service/reservation, or another configured subtype. The subtype can change labels, visible fields, actions, and destination.
My Orders does not prove grouped membership, gift credential safety, custom- order creation, service fulfillment, financial totals, or downstream action availability. Each subtype destination must re-authorize its exact current data without exposing credential-bearing or unrelated account graphs.
Troubleshoot safely
My Orders or one section is missing
Treat the current account/project/session or section state as unresolved. Do not use a private route, another account, or guessed order reference to force it.
One section loads while another remains busy
Keep their states separate. Do not infer that the visible section is a complete or current order history.
A section is empty or errors
Do not send a test message, change Favorite, start Reorder, or refresh repeatedly to discover whether an order exists.
A card moves, disappears, or returns
Treat status/filter/event freshness as unknown. Do not infer cancellation, refund, deletion, or payment outcome.
A card appears after account or project change
Stop and avoid opening or acting on it. The prior account/project generation must be discarded.
A Favorite, Review, Reorder, detail, or downstream Help action behaves unexpectedly
Keep the list and destination outcomes separate. Do not repeat the action or use another order as a test.
Realtime disconnects and reconnects
Do not infer that missed orders or updates were replayed. Wait for the owning section to present a reconciled current state.
Accessibility and privacy
The Orders tab, section headings, loading/empty/error/pagination states, each minimal card, status/time, grouped/subtype label, refresh, and every separate action need clear semantic names, roles, states, announcements, focus order, and predictable return. Large text must not hide status or section identity; screen readers must not merge cards or read hidden/private action data.
Do not include order references, contact/location details, amounts, gift or payment data, messages, provider state, or card screenshots in documentation, logs, support notes, or fixtures. These are verification requirements, not a current accessibility, privacy, or freshness certification.
When to recertify
Repeat isolated review after changes to My Orders entry; preorder/active/past filters; independent reads/loading/error/pagination; refresh; card minimal DTO/ status/time/business presentation; account/guest ownership; grouped/gift/custom/ service subtype handoffs; favorite/help/review/reorder/detail actions; socket rooms/listeners/reconnect cleanup; remote media; accessibility; or App/ components/API authority pins.
Related guides: Understand order details and status · Track an order · Review a reorder option · Understand order messages · Find Customer App help · Use the app offline and reconnect