Repository navigation
Conversation
…(0.47.0) - JobStatus and JobProcessingStatus gain REJECTED. JobInformation.status and JobDetails.processing_status accept unrecognized values as plain str. - skip_preflight on CreateWorkflow, UpdateWorkflow and WorkflowInformation. - scripts/check_spec_drift.py plus a weekly workflow that flags API fields and enum values the SDK models do not cover. Refs DTPL-696 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
There was a problem hiding this comment.
All reported issues were addressed across 26 files
Shadow auto-approve: would not auto-approve because issues were found.
View guided diff | Re-trigger cubic
…(DTPL-696) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
There was a problem hiding this comment.
0 issues found across 2 files (changes from recent commits).
Shadow auto-approve: would not auto-approve. This PR does not meet the repository auto-approval settings.
View guided diff | Re-trigger cubic
Merge main while retaining the authored 0.47.0 feature release and user-agent. Keep the full 0.46.5 keepalive changelog and prior release history verbatim. All runtime and test changes merge automatically. Validated 419 unit tests and 71 contract tests. Four localhost socket tests needed bind permission and passed without source changes. Refs DTPL-696
paulkarayan
left a comment
There was a problem hiding this comment.
Approving with one real ask and two nits.
The contract checks out against platform-api main and the live spec: REJECTED is spelled the same on both enums, create treats null/false as one state, update treats null as unchanged, and the SDK only puts skip_preflight on the wire when it's set. Reverting the model files makes the new contract tests fail, so they're testing the change. 419 unit / 71 contract pass locally on the head.
The ask: a caller who gets JobStatus.REJECTED still can't find out why. The server only puts the reason on each node of /details (failure_category, failure_reason), JobNodeDetails doesn't have either field, and pydantic drops them. JobDetails.message is only set when that detail is missing. So we fixed the crash, but the reason still isn't reachable. I'd add both fields to JobNodeDetails here (failure_category as Union[PreflightFailureCategory, UnrecognizedStr], same pattern as status) and drop them from the baseline. If you'd rather do it as a follow-up, say so in the body, because right now that gap only shows up in spec_drift_baseline.json.
Nits:
- The body still says the 0.46.3 split-PDF fix is folded into 0.47.0, and that's no longer true now that main ships 0.46.3 on its own. The first Validation block also still says 324/74.
- The overlay_client.yaml entries for JobStatus/JobProcessingStatus are dead now that the generator is gone, and x-speakeasy-unknown-values would give the OpenEnumMeta style rather than the Union you actually shipped. I'd drop them.
…(DTPL-696) Drop the dead JobStatus/JobProcessingStatus overlay entries; the generator that read them is gone and the shipped models use a Union instead.
There was a problem hiding this comment.
All reported issues were addressed across 9 files (changes from recent commits).
Shadow auto-approve: would not auto-approve because issues were found.
Tip: Review your code locally with the cubic CLI to iterate faster.
View guided diff | Re-trigger cubic
Reconcile release notes and versions without changing authored behavior. Retain main dependency updates and the exact certifi lock record. All nonmetadata files equal the automatic merge of main.
cragwolfe
left a comment
There was a problem hiding this comment.
Reviewed exact head 4aeb58adb1d4d6c9da34684b50cafeb55dfb62ae with GPT Pro. No actionable defects found.
Known job statuses retain their enum identity; future values remain strings. Rejection diagnostics and workflow skip_preflight serialization have meaningful contract coverage. The prior inline-enum drift, fetch-failure reporting, and overlapping-run findings are addressed in the current source.
All 20 reported checks on this head passed. The scheduled spec-drift workflow has no execution result in that rollup. No local tests were run.
(authored by codex)
What
Jobs the new preflight check rejects no longer break the SDK. Workflows can also opt out of preflight from the SDK.
Before, after a job is rejected:
After:
JobStatusandJobProcessingStatusgainREJECTED.JobInformation.statusandJobDetails.processing_statusalso accept unknown values. Known values are still enum members, sojob.status == JobStatus.COMPLETEDand.valuebehave as before.JobNodeDetailsgainsfailure_category(Union[PreflightFailureCategory, str]) andfailure_reason, so a caller can see why a job was rejected. The server sets them only on the node that failed preflight; before this, pydantic dropped them.skip_preflightis now onCreateWorkflow,UpdateWorkflow(unset = unchanged) andWorkflowInformation. For a one-offcreate_job, the API defines the flag inside therequest_dataJSON. The docs now say to set it there; the SDK does not rewrite that string.Why
The SDK models used to be regenerated from the API spec every night. That generator has been dead since January (removed in #349). Since then, new server values reach the SDK only when someone adds them by hand.
REJECTEDdidn't get added, and a closed enum turns a new value into a hard failure.This PR also adds a way to catch that kind of drift before a customer does (DTPL-696 acceptance criterion 4):
make check-spec-driftruns the check locally. Gaps we already know about are recorded inscripts/spec_drift_baseline.json(20 schemas today, e.g.JobInformation.processing_status, theteradataconnector type). The check fails only on new drift, or on a baseline entry that has since been covered.CONTRIBUTING.mddocuments how to resolve a drift issue.Replaces #353, which got here through a custom
_missing_enum hook and code that spliced bytes intorequest_data. This version uses a plain pydantic union and leavesrequest_dataalone.Notes for consumers
Union[JobStatus, str]/Union[JobProcessingStatus, str]. Code that reads.valueor.nameon them needs to handle thestrcase. Runtime behavior for known statuses is unchanged.Strategy, etc.) useOpenEnumMeta/validate_open_enum. On Python 3.12+ those return a rawstreven for known values, and they emit pydantic serializer warnings. The long-term fix is to move them to the same union pattern used here. That changes their runtime types, so it belongs in its own PR.Validation
make test-unit: 419 passed.make test-contract: 72 passed. The new job/workflow contract tests pass on Python 3.11, 3.12 and 3.13, and they fail without the model changes.make lintis clean.make check-spec-driftpasses against the live specs.Maintenance validation (2026-10-19, keepalive base refresh)
Review follow-up (2026-10-20)
failure_category/failure_reasontoJobNodeDetailswith a newPreflightFailureCategoryenum, and dropped both from the drift baseline. A new contract test covers a known category, an unknown category (plainstr) and a passing node (both null); it passes on 3.11, 3.12 and 3.13.JobStatus/JobProcessingStatusentries fromoverlay_client.yaml. Nothing reads the overlay since the generator was removed, andx-speakeasy-unknown-valueswould describe theOpenEnumMetastyle, not the union shipped here.make test-unit419 passed,make test-contract72 passed,make lintclean,make check-spec-driftclean against the live specs.