Uber Eats CLI: fix unsafe address state, item customizations, and past-order reorders

[prateek]

Summary

The Uber Eats CLI has several issues that make ordering unreliable and potentially unsafe. In a real ordering session, the CLI mixed address contexts, failed to rebuild a visible past order, could not express item customizations, and treated a transient Uber API failure as a hard failure.

The highest-risk bug is address state. The CLI reported Frankfurt as the default/session location while searches and carts were for 222 E 39th St, New York, NY. Checkout should be blocked when the CLI cannot prove the cart address matches the intended delivery address.

Session Evidence

Commands run from this repo:

go run ./cmd/ordercli ubereats orders list --filter past --limit 100 --json
go run ./cmd/ordercli ubereats orders show 42a1051f-aebf-4f54-acd2-e9bbc5813c4d --json
go run ./cmd/ordercli ubereats carts create --from-order 42a1051f-aebf-4f54-acd2-e9bbc5813c4d --json
go run ./cmd/ordercli ubereats addresses show default --json
go run ./cmd/ordercli ubereats carts list --json --limit 20
go run ./cmd/ordercli ubereats carts checkout b0596118-b166-4b6b-9903-2ed130dd003f --json

Observed behavior:

• orders list --filter past --limit 100 returned Rosa Mexicano order 42a1051f-aebf-4f54-acd2-e9bbc5813c4d.
• orders show 42a1051f-aebf-4f54-acd2-e9bbc5813c4d failed with order "..." not found.
• carts create --from-order 42a1051f-aebf-4f54-acd2-e9bbc5813c4d failed with the same not-found error.
• addresses show default returned Konrad-Adenauer-Straße 7, 60313 Frankfurt.
• Existing carts and the Rosa cart were for 222 E 39th St, New York, NY.
• Cart JSON showed address: 222 E 39th St, New York, NY while session.location still said Frankfurt.
• A carts show call failed with ubereats: https://www.ubereats.com/_p/api/getDraftOrderByUuidV1 status 503 for an existing cart.

Problems

1. Unsafe address state

DefaultLocation prefers TARGET, and cart/session metadata is populated from that location even when the cart itself has a different delivery address.

Relevant code:

• internal/ubereats/client.go: DefaultLocation, sessionInfoFromLocation, instructionLocationPayload
• internal/ubereats/cart.go: createCart, GetCart, updateDraftOrderPayload
• internal/cli/ubereats_cmd.go: addresses show, carts checkout

Expected behavior:

• The CLI should have one explicit delivery address context for search, cart creation, cart mutation, preview, and checkout.
• Preview should warn when the cart address differs from the intended address.
• checkout --confirm should be blocked when the cart address and intended address differ.
• Cart output should not stamp misleading session metadata from DefaultLocation when the cart already has its own address.

Proposed fixes:

• Add --address <ref|default> to Uber Eats search, store, item, cart, and checkout commands.
• Add ubereats addresses use <ref> to persist an intended delivery address.
• Before checkout confirmation, compare the cart-native address with the intended address.
• Require an explicit override for mismatches, if we want one at all.
• Prefer cart-native delivery address in cart/session output.

2. Item customization support is incomplete

Manual cart item create/add supports base items only. The CLI blocks required customization groups and omits optional customization choices. This prevents it from modeling normal menu items with spice levels, sauces, add-ons, removals, protein choices, and similar modifiers.

Relevant code:

• internal/ubereats/cart.go: CreateCartFromItem, AddCartItem, itemRequiresCustomization, cartLineFromMenuItem
• internal/ubereats/catalog.go: ItemDetail, CustomizationGroup, CustomizationOption

Expected behavior:

• Users can inspect customization groups and select options.
• Required groups are validated before cart mutation.
• Optional groups are supported.
• Sold-out options are rejected.
• Past-order reorder preserves previous customizations when available.

Possible CLI shape:

ordercli ubereats items show <item-ref> --store <store-ref> --json

ordercli ubereats carts items add <cart-ref> \
  --item <item-ref> \
  --option <group-ref>:<option-ref> \
  --option <group-ref>:<option-ref>

Refs should be the first supported API. Name matching can come later.

3. Past-order lookup is inconsistent

orders list --filter past can show an order that orders show and carts create --from-order cannot find.

Relevant code:

• internal/ubereats/client.go: ListOrders, GetOrder, pastOrderResponses
• internal/ubereats/cart.go: CreateCartFromOrder, findOrderSeed

Expected behavior:

• If a past order appears in list output, orders show <uuid> resolves it.
• carts create --from-order <uuid> uses the same lookup surface or returns a diagnostic explaining that the order lacks reorderable seed data.
• Tests should cover list/show/reorder consistency for the same UUID.

4. No real last 60 days support

The CLI only supports --limit for past orders. In the session, --limit 100 returned 49 dated orders back to March 30, 2026, which was not enough to answer a request for the last 60 days.

Relevant code:

• internal/cli/ubereats_cmd.go: orders list
• internal/ubereats/client.go: pastOrderResponses

Expected behavior:

ordercli ubereats orders list --filter past --since 2026-02-24 --json

The client should page until the cutoff or until Uber stops returning more history. If it cannot cover the requested range, it should print a coverage warning.

5. Transient API failures need retry handling

A cart lookup hit getDraftOrderByUuidV1 status 503 for an existing cart. Read-only calls should retry with bounded backoff.

Relevant code:

• internal/ubereats/client.go: postRaw
• internal/ubereats/cart.go: fetchCartDetail

Expected behavior:

• Retry safe read-only calls on 502, 503, 504, and network resets.
• Do not blindly retry checkout confirmation or other side-effecting calls.

6. Cart item add UX is too easy to misuse

I naturally tried:

ordercli ubereats carts items add <cart-ref> <item-ref>

The command only accepts <cart-ref> and requires --item <item-ref>. This is not a correctness bug, but accepting the item ref positionally would reduce operator mistakes.

Relevant code:

• internal/cli/ubereats_cmd.go: newUberEatsCartItemsAddCmd

Suggested Priority

1. P0: Address state and checkout blocking.
2. P1: Item customization support.
3. P1: Past-order lookup and reorder consistency.
4. P2: Date-bounded history coverage.
5. P2: Retry handling for read-only calls.
6. P3: Cart item add UX.

Acceptance Criteria

• checkout --confirm is blocked when cart address and intended address disagree.
• Cart output no longer shows misleading session.location.
• orders show <uuid> works for UUIDs returned by orders list --filter past.
• carts create --from-order <uuid> either succeeds or explains why the order lacks reorderable seed data.
• Cart item add/create supports required and optional customization groups.
• Past-order listing supports --since and warns when coverage is incomplete.
• Read-only Uber Eats calls retry transient 5xx failures.
• Tests cover address mismatch, customization validation, past-order lookup consistency, date-bounded history, and retry behavior.