Skip to content

Fix wait_for_job for create_extract job ids (#1093) - #1882

Open
jacalata wants to merge 1 commit into
developmentfrom
jac/1093-create-extract-jobs-note
Open

jacalata wants to merge 1 commit into
developmentfrom
jac/1093-create-extract-jobs-note

Conversation

@jacalata

Copy link
Copy Markdown
Contributor

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

Tableau Server returns a JobItem from create_extract on datasources and
workbooks whose id is not addressable via GET /jobs/{id} -- that call
raises ServerResponseError with code 400031. The id IS visible through
the paginated /jobs listing endpoint.

wait_for_job now catches the 400031 error and transparently falls back
to polling /jobs, matching on id, and translating the resulting
BackgroundJobItem into a JobItem so the return type stays stable.
Callers that use wait_for_job are covered without changing their code.
Direct callers of get_by_id still see the raw server error.

BackgroundJobItem carries fewer fields than JobItem, so the translated
JobItem returns defaults for the missing fields (documented in the
wait_for_job docstring). Success/Failed/Cancelled map to their
FinishCode; anything else keeps completed_at=None so the outer poll
loop re-polls, with finish_code=-1 as a sentinel so a reader inspecting
finish_code alone can't mistake an unfinished job for Success.

Six new pytest cases cover the happy path (no listing hit), fallback
happy/failed/cancelled, in-progress iteration, multi-page pager walk,
timeout in the fallback, non-400031 propagation, and job-not-in-listing
(re-raises 400031).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Copilot AI lite review requested due to automatic review settings September 18, 2026 20:45

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Approval recommended

The fallback is narrowly scoped, preserves existing error behavior, and has comprehensive regression coverage.

Pull request overview

Adds a targeted fallback for unqueryable create_extract job IDs while preserving existing get_by_id behavior.

Changes:

  • Polls the paginated jobs listing when GET /jobs/{id} returns error 400031.
  • Translates listing results into stable JobItem instances.
  • Adds regression tests and documents the server quirk.
File summaries
File Description
tableauserverclient/server/endpoint/jobs_endpoint.py Implements fallback polling and JobItem conversion.
tableauserverclient/server/endpoint/datasources_endpoint.py Documents the datasource extract behavior.
tableauserverclient/server/endpoint/workbooks_endpoint.py Documents the workbook extract behavior.
test/test_job.py Adds fallback, pagination, timeout, and error-propagation tests.
Review details
  • Files reviewed: 4/4 changed files
  • Comments generated: 0
  • Review effort level: Lite

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

server.jobs.wait_for_job fails for ID generated by create_extract

2 participants