GeezerVison

Closes #1093.

Motivation

server.jobs.wait_for_job(job) crashes on JobItems returned by datasources.create_extract and workbooks.create_extract: the server answers GET /jobs/{id} for those ids with ServerResponseError code 400031: There was a problem querying job '{id}'.. The id IS visible through the paginated /jobs listing endpoint.

Reported in 2022, still reproduces on rel-windows on-prem 3.30 and stage-dataplane1 Cloud 3.30 against the monolith's Batters (TestV1).tdsx today (2026-09-18). Public docs don't mention this quirk.

Behavior change

• wait_for_job catches the specific 400031 error from get_by_id and falls back to polling the paginated /jobs listing (Pager(server.jobs) with pagesize=1000, matching on id).
• The BackgroundJobItem the listing returns is translated into a JobItem so the return type stays stable. Fields absent from BackgroundJobItem come back as documented defaults (progress="", notes=[], status_notes=[], plus several Nones — documented in the wait_for_job docstring).
• Terminal statuses (Success / Failed / Cancelled) map to their JobItem.FinishCode. Anything else — Pending, InProgress, an unknown future status, missing status — keeps completed_at=None so the outer poll loop re-polls, with finish_code=-1 as a sentinel so a reader inspecting finish_code without gating on completed_at can't mistake an unfinished job for Success.
• Jobs.get_by_id is unchanged. Direct callers still see the raw server error; the fallback only kicks in through wait_for_job.
• If wait_for_job gets 400031 AND the id isn't in the listing (only fires on a rare create-vs-listing race), the original 400031 is re-raised — no new exception type invented.
• Any ServerResponseError with a code other than 400031 propagates untouched — no listing fallback.

The create_extract docstrings on datasources_endpoint.py and workbooks_endpoint.py note the quirk and point callers at wait_for_job for transparent handling. wait_for_job's own Notes section describes the fallback + the synthesized-field defaults.

Test plan

• Six new pytest cases in test/test_job.py:
  • happy path (no listing hit — sanity guard against future regressions)
  • fallback success / failed / cancelled
  • fallback in-progress → success (verifies the outer poll loop iterates through the fallback)
  • fallback walks multiple listing pages
  • fallback timeout (deterministic via mocked_time)
  • fallback where id isn't in the listing (re-raises 400031)
  • non-400031 propagation (no listing fallback fires)
• Full suite: pytest test/ → 936 passed / 1 skipped.
• black --check clean; mypy 0 issues across 214 files.
• Manually verified 400031 reproduces fresh on 2026-09-18 on rel-windows and stage-dataplane1 using the monolith's Batters (TestV1).tdsx.

🤖 Generated with Claude Code