Skip to content

communications.list_rfqs / list_quotes accept status: str | None — should be Literal-narrowed #324

Closed

Description

@TexasCoding

Problem

Every other paginated list(...) that takes a status= kwarg narrows it to a Literal alias (OrderStatusLiteral, IncentiveProgramStatusLiteral, etc.). CommunicationsResource.list_rfqs and list_quotes (sync + async) are the only resources where status is bare str. The Kalshi spec defines closed enums for RFQ status and Quote status; the SDK simply hasn't declared the Literal aliases.

Concrete impact: client.communications.list_rfqs(status="accpeted") (typo) round-trips to the server (which returns 200 with an empty result depending on filter semantics) instead of being flagged at the call site by mypy/IDE autocomplete. The SDK README advertises "Literal types on fixed-enum kwargs" as a headline feature; the gap here breaks that promise. UserFilterLiteral already lives in the same module, so the pattern is in place.

Evidence

  • kalshi/resources/communications.py:213-235 — list_rfqs:
def list_rfqs(
    self,
    *,
    ...
    status: str | None = None,
    ...
    user_filter: UserFilterLiteral | None = None,
    ...
) -> Page[RFQ]:
  • kalshi/resources/communications.py:334-355 — list_quotes:
def list_quotes(
    self,
    *,
    ...
    status: str | None = None,
    ...
    user_filter: UserFilterLiteral | None = None,
    rfq_user_filter: UserFilterLiteral | None = None,
    ...
) -> Page[Quote]:
  • kalshi/resources/orders.py:447-473 — peer pattern uses Literal:
def list(
    self,
    *,
    ...
    status: OrderStatusLiteral | None = None,
    ...
) -> Page[Order]:
  • kalshi/models/communications.py:11-12 — Literal pattern already established here:
UserFilterLiteral = Literal["self"]

Suggested fix

In kalshi/models/communications.py, add RfqStatusLiteral and QuoteStatusLiteral aliases mirroring the spec enum values. Export from kalshi/__init__.py. Narrow status kwargs on list_rfqs, list_all_rfqs, list_quotes, list_all_quotes (sync + async). If the spec leaves either enum open-ended, use Literal[...] | str so existing callers keep working but autocomplete still surfaces the canonical set.

Source

Round-3 independent audit (reviewer: resources_api).

Metadata

Metadata

Assignees

No one assigned

    Labels

    polishCode-quality and DX improvements; non-functionalspec-driftUpstream OpenAPI/AsyncAPI spec changed since last sync

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions