Conversation
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>
There was a problem hiding this comment.
🟢 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 error400031. - Translates listing results into stable
JobIteminstances. - 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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #1093.
Motivation
server.jobs.wait_for_job(job)crashes onJobItems returned bydatasources.create_extractandworkbooks.create_extract: the server answersGET /jobs/{id}for those ids withServerResponseErrorcode400031: There was a problem querying job '{id}'.. The id IS visible through the paginated/jobslisting 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).tdsxtoday (2026-09-18). Public docs don't mention this quirk.Behavior change
wait_for_jobcatches the specific400031error fromget_by_idand falls back to polling the paginated/jobslisting (Pager(server.jobs)withpagesize=1000, matching onid).BackgroundJobItemthe listing returns is translated into aJobItemso the return type stays stable. Fields absent fromBackgroundJobItemcome back as documented defaults (progress="",notes=[],status_notes=[], plus severalNones — documented in thewait_for_jobdocstring).JobItem.FinishCode. Anything else — Pending, InProgress, an unknown future status, missing status — keepscompleted_at=Noneso the outer poll loop re-polls, withfinish_code=-1as a sentinel so a reader inspectingfinish_codewithout gating oncompleted_atcan't mistake an unfinished job for Success.Jobs.get_by_idis unchanged. Direct callers still see the raw server error; the fallback only kicks in throughwait_for_job.wait_for_jobgets 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.ServerResponseErrorwith a code other than400031propagates untouched — no listing fallback.The
create_extractdocstrings ondatasources_endpoint.pyandworkbooks_endpoint.pynote the quirk and point callers atwait_for_jobfor transparent handling.wait_for_job's own Notes section describes the fallback + the synthesized-field defaults.Test plan
test/test_job.py:mocked_time)pytest test/→ 936 passed / 1 skipped.black --checkclean;mypy0 issues across 214 files.Batters (TestV1).tdsx.🤖 Generated with Claude Code