feat: parse <statusNotes>/<statusNote> into JobItem.status_notes (#1850) - #1852
Open
jacalata wants to merge 1 commit into
Open
feat: parse <statusNotes>/<statusNote> into JobItem.status_notes (#1850)#1852jacalata wants to merge 1 commit into
jacalata wants to merge 1 commit into
Conversation
The REST Query Job response schema documents a structured status-notes
block:
<statusNotes>
<statusNote type="CountOfUsersAddedToSite" value="5" text="..." />
<statusNote type="CountOfUsersSkipped" value="1" text="..." />
</statusNotes>
JobItem was parsing only the sibling legacy `<notes>` element (emitted
by some job types like extractRefreshJob), missing the modern
statusNotes entirely. For UserImport jobs and any other multi-row job
where individual rows have distinct outcomes, `job.notes` came back as
an empty list even when the server had sent detailed structured status.
Add `JobItem.status_notes: list[dict]`, each dict with keys `type`,
`value`, `text` (any of which may be None if the server omitted them).
The legacy `notes: list[str]` attribute is unchanged for backwards
compatibility -- it still parses the `<notes>` element still emitted by
extract-refresh and similar older job types.
Verified against the public REST doc:
https://help.tableau.com/current/api/rest_api/en-us/REST/rest_api_ref_jobs_tasks_and_schedules.htm#query_job
The existing job_get_by_id.xml test asset already contained a
statusNotes block; the get_by_id test now asserts the structured value
in addition to the legacy notes list. Two new tests cover the absent
case (yields []) and the multi-note case with attribute omissions.
Discovered while planning tabcmd createsiteusers nowait / silent-progress
work (tableau/tabcmd#35); a live probe against Tableau Server 2025.1
confirmed the server emits this schema for UserImport jobs.
Fixes #1850.
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.
Summary
The REST Query Job response schema documents a structured status-notes block:
JobItemwas parsing only the sibling legacy<notes>element (emitted by some job types likeextractRefreshJob), missing the modernstatusNotesentirely. ForUserImportjobs and any other multi-row job where individual rows have distinct outcomes,job.notescame back as an empty list even when the server had sent detailed structured status.Fix
Add
JobItem.status_notes: list[dict], each dict with keystype,value,text(any of which may beNoneif the server omitted them). The legacynotes: list[str]attribute is unchanged for backwards compatibility — it still parses the<notes>element still emitted by extract-refresh and similar older job types.Verification
test/assets/job_get_by_id.xmltest asset already contains both a<notes>element and a<statusNotes>/<statusNote>block.test_get_by_idnow asserts the structured value in addition to the legacy notes list.POST /sites/<id>/users/import+GET /sites/<id>/jobs/<job-id>— the server sends<statusNote type="line" value="0" />,<statusNote type="errorCode" value="1" />, etc. for failures. The priorjob.noteswas[]for these responses.Closes #1850.
Test plan
test/test_job.py::test_get_by_idaugmented to assert the structuredstatus_notesfrom the existing assettest_status_notes_empty_when_absent— job with no<statusNotes>yields[]test_status_notes_multiple_entries— 4-entry list, exercises thetextattribute coming back asNonewhen omittedtest_job.pysuite: 16 passedDiscovered while
Planning tabcmd
createsiteusers --nowait/--silent-progresswork (tableau/tabcmd#35). Switching from the per-userusers.addloop tobulk_add+wait_for_jobfor Classic parity needs per-row status back — which needed this data.🤖 Generated with Claude Code