Implement mobile feed functionality in mobile-client

[marioinkfnd]

This pull request introduces the global trade feed API to the mobile client, enabling fetching, filtering, and paginating public trade feed data. The main changes include implementing the getFeed method in MobileClient, defining new client and server types for feed data, adding data mapping utilities, and expanding error codes. It also refactors the query methods for improved type safety and consistency.

Global Feed API Implementation

• Added the getFeed method to MobileClient, allowing clients to fetch pages of the global trade feed with optional filtering and pagination. (F8a701d8L135R177)
• Defined new client-side types: MobileFeedMargin, MobileFeedTrade, MobileFeedPage, and GetMobileFeedParams in clientTypes.ts, describing the shape of feed data and request parameters. (Fc5f57eaL45R112, Fc5f57eaL163R163)
• Added server-side request/response types for the feed (feed entry in MobileServerPublicQueryRequestByType) and updated discriminant types.

Data Mapping Utilities

• Implemented mapMobileFeedPage, mapMobileFeedTrade, and mapMobileFeedMargin in dataMappers.ts to convert server-side feed data to client-side representations. (Ff4aa0bdL96R96)

Error Handling

• Added new mobile error codes for feed-specific errors: INVALID_FEED_FILTER and INVALID_FEED_CURSOR in mobileErrorCodes.ts.

Type Safety and Query Refactoring

• Refactored publicQuery and query methods in MobileClient to use discriminated union types for request/response, improving type safety and consistency. (F8a701d8L340R367)

Testing

• Added an end-to-end test suite for the feed API in feed.test.ts, covering fetching, filtering, pagination, and error handling.

[claude]

Claude Code Review

This repository is configured for manual code reviews. Comment @claude review for a one-time review, or @claude review always to subscribe this PR to a review on every future push.

_{Tip: disable this comment in your organization's Code Review settings.}

[frankinkfnd]

If we now have MobileServerPublicQueryResponseByType, etc., why do we still need MobileServerPublicQueryType / MobileServerSuccessResponse?

Just to clarify - engine defines the server query params + response types, then builds EngineServerQueryRequestByType, and EngineServerQueryRequest / EngineServerQueryRequestType is derived based on that. Is this structure possible for mobile?

[marioinkfnd]

Yep, done — it's now the engine structure with matching names.

Engine

flowchart TD
    subgraph ENGINE["engine-client — single query endpoint"]
        EP["per-query param interfaces<br/>(EngineServerMarketPriceQueryParams, ...)"] --> ERBT["EngineServerQueryRequestByType<br/>source of truth<br/>(param-less = Record&lt;string, never&gt;)"]
        ERBT -- "keyof" --> ERT["EngineServerQueryRequestType"]
        ERBT -- "{ type: T } &amp; RequestByType[T]" --> ER["EngineServerQueryRequest&lt;T&gt;"]
        ERES["per-query response interfaces<br/>(EngineServerMarketPriceResponse, ...)"] --> ERESBT["EngineServerQueryResponseByType<br/>(raw payloads)"]
        ERESBT -- "{ status: 'success', data: ResponseByType[T] }<br/>payload NESTED under data" --> ESR["EngineServerQuerySuccessResponse&lt;T&gt;"]
    end

Loading

Mobile

flowchart TD
    subgraph PUB["mobile-client — public_query endpoint"]
        MRBT["MobileServerPublicQueryRequestByType<br/>source of truth"]
        MRBT -- "keyof" --> MRT["MobileServerPublicQueryRequestType"]
        MRBT -- "{ type: T } &amp; RequestByType[T]" --> MR["MobileServerPublicQueryRequest&lt;T&gt;"]
        MRES["per-query payload interfaces<br/>(MobileServerFeedResponse, ...)"] --> MRESBT["MobileServerPublicQueryResponseByType<br/>(raw payloads)"]
    end

    subgraph SIG["mobile-client — signed query endpoint"]
        SRBT["MobileServerSignedQueryRequestByType<br/>all Record&lt;string, never&gt;<br/>(caller identified by signature)"]
        SRBT -- "keyof" --> SRT["MobileServerSignedQueryRequestType"]
        SINNER["MobileSignedInner<br/>+ signature / sender / nonce"] --> SREQ["MobileSignedRequest<br/>(wire request = signed envelope)"]
        SRES["per-query payload interfaces<br/>(MobileServerSelfIdentityResponse, ...)"] --> SRESBT["MobileServerSignedQueryResponseByType<br/>(raw payloads)"]
    end

    ENV["MobileServerSuccessResponse<br/>{ status: 'success' }<br/>shared base envelope"]
    MRESBT --> MSR["MobileServerPublicQuerySuccessResponse&lt;T&gt;"]
    ENV -- "envelope &amp; ResponseByType[T]<br/>payload INLINED next to status" --> MSR
    SRESBT --> SSR["MobileServerSignedQuerySuccessResponse&lt;T&gt;"]
    ENV -- "envelope &amp; ResponseByType[T]" --> SSR
    ENV -- "returned as-is (no payload)" --> EXEC["execute routes<br/>(claim_username, register_expo_token, ...)"]

Loading

• MobileServerPublicQueryRequestByType is the source of truth (renamed from ParamsByType), and MobileServerPublicQueryRequestType / MobileServerPublicQueryRequest<T> are derived from it via keyof — exactly like engine.
• *ResponseByType now holds raw payloads (like EngineServerQueryResponseByType) and the full response is derived: MobileServer*QuerySuccessResponse<T> = MobileServerSuccessResponse & ResponseByType[T].
• MobileServerSuccessResponse is no longer a per-query wrapper — just the bare { status: 'success' } envelope. It exists because mobile inlines payloads next to status (no data key), and the executes return it as-is.
• Signed queries got the same treatment (MobileServerSignedQueryRequestByType with empty objects, like engine's param-less queries).

Only structural diffs left, all forced by the API: payload inlined instead of nested under data, two parallel chains because public_query / signed query are separate endpoints, and on the signed route the wire request is the signed envelope rather than { type } & params.

[frankinkfnd]

Do we need to export a type for these? It's a bit confusing as I would have thought the request params would be retrieved via MobileServerPublicQueryRequestByType

[marioinkfnd]

Deleted all three. The call sites in MobileClient now annotate with the generic directly, e.g. const body: MobileServerPublicQueryRequest<'feed'>.

One thing I tried and backed out: giving publicQuery a MobileServerPublicQueryRequest<T> param. That type is an indexed access on a mapped type, which isn't an inference site, so T widened to the full union and every caller lost its response narrowing. It keeps the { type: T } & MobileServerPublicQueryRequestByType[T] intersection, with a comment saying why.

[frankinkfnd]

@marioinkfnd can you look at the test cancelling? seems like a timeout

[marioinkfnd]

@marioinkfnd can you look at the test cancelling? seems like a timeout

I bumped timeout but it still seems like it takes too long. Should I keep it as it is or?

[frankinkfnd]

There seems to be an error with the test:

but also, why are the feed tests so slow?

[marioinkfnd]

There seems to be an error with the test:

but also, why are the feed tests so slow?

[frankinkfnd]

@marioinkfnd can you raise this to Jonathan as well as the query_public_feed issue?

Will publish this as it's not in prod

[frankinkfnd]

0.30.0