v0.53.0

@pipelex/sdk on npm

Added

• readProblemItems: reads a verdict's errors or warnings as the standard's ProblemItems member by member, so an item whose code or detail is not a string is skipped and a member that does not fit is left out of its item, as every verdict of the SDK reads them.
• RunFailedError.runError and the failed arm's problem: a failed run's error and the failed arm of getRunResult carry the results read's run.failed document as problem, and the run's own problem, which it nests as run_error, as runError on the error and error on the arm, under its own code (run.cancelled, model.unavailable, method.invalid, …).
• A shared case file of the problems the SDK builds: tests/fixtures/sdk-problems.json, copied from js/ into python/, pins every failure the SDK detects itself, every class's problem and the reading of every bare answer to its problem code, and both suites run it.

Changed

• Every error carries its failure as one problem document (Breaking): every error the SDK throws is the standard's ProblemError, carrying an RFC 9457 problem document with the MTHDS core members as problem and reading it through code, domain, retry, nextStep, retryAfter and requestId; a hosted refusal is the problem document the API answered, a failed run's problem is the one the platform stored, and a failure the SDK detects itself, such as a refused argument, a request that got no answer, an answer it cannot read or a start whose outcome is unknown, is a problem it builds under a client.* code or another core code. Branch on code, never on the class, the status or the message, which stays the SDK's own sentence.
• ApiResponseError reads the answer as its problem (Breaking): its problem is the body as received when it is a problem document, a pipelex.* code and every member the standard does not name included, and otherwise the reading of the edge's bare answer by its status, client.outcome_unknown for a start or an execute the gateway cut off; apiUrl, status, statusText and responseBody keep the answer itself. ApiResponseErrorOptions is { cause, problem, headers, mayStartRun }: details is problem again, as the Python twin names it.
• A start whose outcome is unknown reads as retry: "outcome_unknown" (Breaking): an error from a start or a blocking execute that may have created a run although the call failed carries client.outcome_unknown, whose retry is outcome_unknown, where it carried runMayHaveStarted: true; PipelineExecuteTimeoutError always carries it.
• A failed run's error is the run's problem (Breaking): RunPublic.error, which the status read carries, the failed arm's error, RunHistoryItem.error and PipelineRun.error are the run's own problem document, or null, read leniently so that anything but a problem document reads as null, where they were the stored RunErrorReport; RunFailedError loses error for runError.
• A progress invocation's last_failure carries its problem (Breaking): ProgressFailure is { problem, at? }, losing message for problem, the standard's Problem in the caller's view: the problem that ended the invocation, or that of the latest failure of an attempt being tried again; getRunProgress keeps a last_failure only when its problem is a problem document, and its at only when it is a string, so read last_failure.problem and branch on its code.
• Verdicts list their faults as problem items (Breaking): PipelexInvalidReport.errors and CrateInvalidReport.errors, a valid verdict's warnings, and MethodLoadError's problem.errors are the standard's ProblemItems, read from the answer's errors member by member, where they were validation_errors of ValidationErrorItems; MethodLoadError loses validationErrors, and the pipelex-sdk command lists a method's faults from them.
• A refused publish's verdict is read as validate reads one: the refused arm of publishMethod reads its validation member by member, so an entry of its errors that names no fault is left out and a verdict listing none lists an empty errors, and a refusal whose validation is not a verdict object with a boolean is_valid throws the ApiResponseError of an answer the SDK cannot read.
• The results read's 409 is read by its code (Breaking): getRunResult reads a 409 run.failed as the failed arm and a 409 run.not_finished as the running arm, whose retry_after_seconds is the problem's retry_after rounded up to whole seconds, else the Retry-After header's, and throws any other 409 as an ApiResponseError, where every 409 was the failed arm.
• A missing route is a 404 that names no code of its own, or request.not_found (Breaking): the lifecycle start and reads, progress included, throw RunLifecycleUnavailableError for a 404 whose body is not a JSON object naming a non-empty string code, such as a bare runner's {"detail": "Not Found"}, and for a request.not_found problem document, the one a runner answers for a path no route serves from pipelex-api 0.90 on, where a body carrying any code member was an ApiResponseError; every other coded 404, such as run.not_found or a method that does not exist, stays an ApiResponseError.
• The method and idempotency codes are registry codes (Breaking): MethodErrorCode is pipelex.catalog.update_conflict, pipelex.catalog.being_deleted, pipelex.catalog.not_published, pipelex.catalog.not_found, pipelex.org.not_found and pipelex.catalog.copy_too_large, and IdempotencyErrorCode is request.idempotency_key_in_use and request.idempotency_conflict.
• A failure's own vocabulary is its reason (Breaking): RejectedAssetError, TestFileRefusedError, UploadTransportError, ArtifactFetchError and MethodFileTransferError name why they failed as reason, typed RejectedAssetReason, TestFileRefusalReason, UploadTransportReason and MethodFileTransferReason, so code is the problem's alone, and ApiUnreachableError names its network failure networkCode.
• The codegen and exact-integer errors carry problems (Breaking): CodegenLockError and ExactJsonUnsupportedError are ProblemErrors, the first stating its cause (client.file_unreadable for a malformed lock, client.tool_outdated for a format this build does not read, client.argument_invalid for a caller's mistake), the second client.tool_outdated naming the JavaScript runtime.
• The .mthds check hook names the verdict's problem items: when the server sends no Markdown, the hook built by npm run build:hook words its block from the invalid verdict's errors[], naming each MTHDS problem item by its code, its sentence and where it happened, with its suggested fix on a line of its own, and it no longer reads validation_errors[]. The items are read as every verdict of the SDK reads them (readProblemItems), so an entry with no code or sentence is skipped and a location or a fix the standard's check refuses is left out of its item (docs/hook-bundle.md).

Fixed

• A download failure the SDK cannot place reads as unknown: an item of downloadArtifacts that failed for a reason neither the fetch nor the write of its file names carries the error.code unknown, where it carried network, which read as a failure a retry can pass, as pipelex-sdk labels it.

Removed

• The verdict vocabulary (Breaking): errorVerdictOf, problemVerdict, ErrorVerdict, ErrorDomain, runMayHaveStartedOf and every error's retryable, errorDomain and runMayHaveStarted are gone, as is the fallback table that decided a verdict from the status; read domain and retry off the problem.
• The hosted members of ApiResponseError (Breaking): errorType, serverMessage, code (now the problem's), type, title, instance, errorCategory, userAction, model, provider, providerMetadata, migration, errors, validationErrors and problemDocument are gone; every one of them is a member of problem, read there.
• The hand-written error and verdict types (Breaking): RunErrorReport, UserAction, ProviderErrorMetadata, MigrationErrorBlock, FieldError, ProblemDetails, ValidationErrorItem, ValidationErrorCategory, SuggestedFix, FixSafety, FixOpKind, FixOp and its variants, and the TomlScalar, TomlValue and FixValue types are gone, replaced by the standard's Problem, ProblemItem, SuggestedFix and FixOp from mthds/protocol.

pipelex-sdk on PyPI

Added

• pipelex_sdk.answer_reading, pipelex_sdk.problem_items and pipelex_sdk.transport_reading: read_hosted_answer reads an answer that is not the route's result as its problem, read_problem_items reads a verdict's errors or warnings as the standard's ProblemItems member by member, and request_may_have_left reads whether a request that got no answer may have left this machine, each the twin of @pipelex/sdk's module of the same name.
• RunFailedError.run_error and RunResultFailed.problem: a failed run's error and the failed arm of get_run_result carry the results read's run.failed document as problem, and the run's own problem, which it nests as run_error, as run_error on the error and error on the arm, under its own code (run.cancelled, model.unavailable, method.invalid, …); nested_run_error reads it off any run.failed.
• A shared case file of the problems the SDK builds: tests/fixtures/sdk-problems.json, copied from @pipelex/sdk, pins every failure the SDK detects itself, every class's problem and the reading of every bare answer to its problem code, and both suites run it.

Changed

• Every error's problem is its verdict (Breaking): every error the SDK raises carries its failure as the standard's Problem, problem, never None: a hosted refusal is the problem document the API answered, its pipelex.* code and every member the standard does not name on problem.model_extra, a failed run's problem is the one the platform stored, and a failure the SDK detects itself, such as a refused argument, a request that got no answer, an answer it cannot read or a start whose outcome is unknown, is a problem it builds under a client.* code or another core code. Branch on problem.code, problem.effective_domain and problem.effective_retry, never on the class, the status or the message.
• ApiResponseError reads the answer as its problem (Breaking): its problem is the body as received when it is a problem document, and otherwise the reading of the edge's bare answer by its status, client.outcome_unknown for a start or an execute the gateway cut off; status, status_text, response_body, headers, request_url, api_url and request_id keep the answer itself, and it takes problem and may_start_run when built by hand.
• A start whose outcome is unknown reads as retry outcome_unknown (Breaking): an error from a start or a blocking execute that may have created a run although the call failed carries client.outcome_unknown, whose retry is outcome_unknown, where it carried run_may_have_started=True; PipelineExecuteTimeoutError always carries it.
• A failed run's error is the run's problem (Breaking): RunRead.error, RunResultFailed.error, RunHistoryItem.error and PipelineRun.error are the run's own Problem, or None, read leniently so that anything but a problem document reads as None, where they were the stored RunErrorReport; RunFailedError loses error for run_error.
• A progress invocation's last_failure carries its problem (Breaking): ProgressFailure loses message for problem, the standard's Problem in the caller's view: the problem that ended the invocation, or that of the latest failure of an attempt being tried again; a last_failure whose problem is not a problem document reads as None, and an at that is not a string reads as None with its problem kept, so read last_failure.problem and branch on its code.
• Verdicts list their faults as problem items (Breaking): PipelexInvalidReport.errors and CrateInvalidReport.errors, a valid verdict's warnings, and MethodLoadError's problem.errors are the standard's ProblemItems, read from the answer's errors member by member and kept as they are when a verdict built in code is given ProblemItems, where they were validation_errors of ValidationErrorItems; MethodLoadError loses validation_errors, and the pipelex-sdk command lists a method's faults from them.
• The results read's 409 is read by its code (Breaking): get_run_result reads a 409 run.failed as the failed arm and a 409 run.not_finished as the running arm, whose retry_after_seconds is the problem's retry_after rounded up to whole seconds, else the Retry-After header's, and raises any other 409 as an ApiResponseError, where every 409 was the failed arm.
• A refused credential reads by its status: UploadAuthenticationError and ArtifactAuthenticationError, raised by upload_file and download_artifacts, carry the server's problem when the route answered one, and otherwise read a bare 401 as auth.missing_credential and a bare 403 as auth.invalid_credential, whether or not the client holds an API key, as @pipelex/sdk reads them; ArtifactCapableClient no longer asks for api_key.
• A missing route is a 404 that names no code of its own, or request.not_found (Breaking): the lifecycle start and reads, progress included, raise RunLifecycleUnavailableError for a 404 whose body is not a JSON object naming a non-empty string code, such as a bare runner's {"detail": "Not Found"}, and for a request.not_found problem document, the one a runner answers for a path no route serves from pipelex-api 0.90 on, where a body carrying any code or error_type member was an ApiResponseError; every other coded 404, such as run.not_found or a method that does not exist, stays an ApiResponseError.
• The method and idempotency codes are registry codes (Breaking): MethodErrorCode is UPDATE_CONFLICT, BEING_DELETED, NOT_PUBLISHED, NOT_FOUND, ORGANIZATION_NOT_FOUND and COPY_TOO_LARGE, valued pipelex.catalog.* and pipelex.org.not_found, and IdempotencyErrorCode is KEY_IN_USE and CONFLICT, valued request.idempotency_key_in_use and request.idempotency_conflict.
• A failure's own vocabulary is its reason (Breaking): RejectedAssetError, TestFileRefusedError, UploadTransportError, ArtifactFetchError and MethodFileTransferError name why they failed as reason, typed RejectedAssetReason, TestFileRefusalReason, UploadTransportReason and MethodFileTransferReason, and ApiUnreachableError names its network failure network_code.
• The codegen errors carry problems: CodegenError and CodegenLockError carry problem as every other error does, each raise site stating its cause: client.file_unreadable for a malformed lock, client.tool_outdated for a format this build does not read, client.write_failed and client.target_exists for a tree the writer cannot write.

Fixed

• A download failure the SDK cannot place reads as unknown: an item of download_artifacts that failed for a reason neither the fetch nor the write of its file names carries the error.code unknown, where it carried network, which read as a failure a retry can pass, as @pipelex/sdk labels it.

Removed

• The verdict vocabulary (Breaking): pipelex_sdk.error_verdicts (error_verdict_of, fallback_verdict, ErrorVerdict, ErrorDomain, run_may_have_started_of) and pipelex_sdk.run_may_have_started are gone, as is every error's retryable, error_domain and run_may_have_started; read effective_domain and effective_retry off the problem.
• The hosted members of ApiResponseError (Breaking): error_type, server_message, code, type_uri, title, instance, error_category, user_action, errors, validation_errors and problem_document are gone; every one of them is a member of problem, read there.
• The hand-written error and verdict types (Breaking): pipelex_sdk.error_models (RunErrorReport, UserAction, ProviderErrorMetadata, MigrationErrorBlock, FieldError, ProblemUserAction, HostedProblemMembers) and the validation models' ValidationErrorItem, ValidationErrorCategory, SuggestedFix, FixSafety, FixOpKind and FixOp variants are gone, replaced by the standard's Problem, ProblemItem, SuggestedFix and FixOp from mthds.protocol.problem.models.

@pipelex/create-method-app on npm, with the method-app templates

Security

• Next.js 16.4.2: the web app template requires next and eslint-config-next at ^16.4.2 and locks 16.4.2, past the Next.js advisories that covered 16.3.8: the critical unauthenticated remote code executions in the Image Optimization API with SVG files (GHSA-2464-fhr4-w9xw) and in use cache functions returning typed arrays (GHSA-673q-mjm6-r5xr), and the denial of service in App Router Server Actions (GHSA-p3m5-59mp-jv5r). The lock also takes sharp 0.35.5, which next 16.4.2 requires, past the librsvg advisory GHSA-wq5f-xc86-pv6w.

The JavaScript starter, Pipelex/pipelex-starter-js

Security

• Next.js 16.4.2: the starter requires next and eslint-config-next at ^16.4.2 and locks 16.4.2, past the Next.js advisories that covered 16.3.8: the critical unauthenticated remote code executions in the Image Optimization API with SVG files (GHSA-2464-fhr4-w9xw) and in use cache functions returning typed arrays (GHSA-673q-mjm6-r5xr), and the denial of service in App Router Server Actions (GHSA-p3m5-59mp-jv5r). The lock also takes sharp 0.35.5, which next 16.4.2 requires, past the librsvg advisory GHSA-wq5f-xc86-pv6w.