entriesForParticipant

Query

All entries (runners) for a participant, ordered by scheduled race time, most recent first. Each Runner exposes its parent race via Runner.race, so callers can render a single round-trip form table.

entityType accepts HORSE / JOCKEY / TRAINER — the resolver routes to the matching column on the entries table. Other types (OWNER) raise a validation error (ownership isn’t a per-race relationship; use the ownership-tracker surface instead).

futureOnly and pastOnly PARTITION the entry set — provided withinDays is not set. Every entry then matches exactly one of them, because pastOnly is compiled as the negation of the futureOnly predicate rather than written separately. A caller can therefore split a participant’s entries across two views with no entry falling between them — which a hand-written “already run” predicate does not guarantee (a runner withdrawn from tomorrow’s race is neither upcoming nor run).

withinDays narrows the FUTURE side only, so it breaks exhaustiveness by design: a race scheduled beyond the window is matched by neither flag. The two remain disjoint, so nothing is ever double-counted, but a caller pairing two views must leave withinDays unset for the pair to be complete. (pastOnly is unaffected — the window is ignored outside future-window mode.)

Future-window mode (for “is this horse scheduled to race again soon?”): set futureOnly: true to restrict to races scheduled at or after now, ordered soonest-first, excluding finished races and inactive entries (NON_DECLARED / NON_RUNNER / WITHDRAWN / DISQUALIFIED). Add withinDays to cap the window (e.g. withinDays: 7). With futureOnly false (the default) the query is the full form history, newest first, unfiltered by status — withinDays is ignored in that mode.

Status filtering (POD-539): pass excludeStatuses to drop entries in the given states from either mode. For a career history of any participant the recommended default is excludeStatuses: [NON_DECLARED] (an entry never declared to run has no run to show — true of a jockey’s rides and a trainer’s runners as much as a horse’s form); add WITHDRAWN and NON_RUNNER to also hide those. Left empty (the default) the result is unfiltered by status, so existing callers are unaffected. The ops UI (POD-619) exposes exactly these three steps as an operator-selectable scope.

Alias-aware (RAC-9858, PRD-011 REQ-010): participantId may be a canonical id or one retired into it by a merge. The result covers every record in that merge cluster, so a merged horse’s form reads as one history and every filter above applies to the retired records’ entries too.

Returns: [Runner!]!

Arguments

Name	Type	Description
entityType	ParticipantEntityType!	—
participantId	ID!	—
limit	Int	—
offset	Int	—
futureOnly	Boolean	When true, restrict to races scheduled at or after now and order ascending (soonest first); also excludes finished races and inactive entries (NON_DECLARED / NON_RUNNER / WITHDRAWN / DISQUALIFIED). Default false = full form history, newest first.
pastOnly	Boolean	The complement of futureOnly — everything an upcoming-races view would NOT show: races already gone off, races that can no longer be run, and inactive entries (a runner withdrawn from tomorrow’s race belongs here, not to futureOnly). Exact when withinDays is unset; withinDays narrows only the future side, leaving races beyond the window in neither. Newest first. Mutually exclusive with futureOnly; asking for both is rejected, since the combination matches nothing.
withinDays	Int	Upper bound on the future window in days from now (e.g. 7). Only applies when futureOnly is true; ignored otherwise. Setting it means futureOnly and pastOnly no longer cover the whole entry set — a race beyond the window matches neither. Must be an integer 1–365.
excludeStatuses	[RunnerStatus!]	Entry statuses to exclude from the result. For any participant’s career history pass [NON_DECLARED] (recommended default) so entries that were never declared are hidden; add WITHDRAWN / NON_RUNNER to also hide those. Empty / omitted = no status filtering.