v0.41.0

@pipelex/sdk on npm

Added

• The methods list's publish state and published filter: MethodSummary carries latest_version, latest_published (a MethodVersionSummary) and draft_digest, each optional and null when it does not apply, draft_digest being null on a row that never stored one until its next draft write, so a list tells a never-published method, one whose draft matches its latest version and one whose draft is ahead apart without reading each method. listMethods and iterateMethods take published, sent as published=true or published=false only when given.
• The run history's createdBy and status filters: listRuns and iterateRuns take createdBy: "me", sent as created_by=me, which keeps the caller's own runs, and status, a list of RunStatus sent as one repeated status= parameter per status in the platform's order, which keeps the runs in any of them; an empty status list or a name that is no RunStatus is a RequestArgumentError before any request. Under these filters, as under q and published on the methods list, a page can come back empty and still carry a nextCursor, and only a null cursor ends the list.

Changed

• iterateRuns follows the cursor through an empty page: it stopped at the first empty page, which under the new filters is not the end of the history, and now runs the same loop as iterateMethods, following the cursor until it is null or stops advancing and throwing PagingNotTerminatingError past the same page ceiling.

pipelex-sdk on PyPI

Added

• The methods list's publish state and published filter: MethodSummary carries latest_version, latest_published (a MethodVersionSummary) and draft_digest, each defaulting to None, draft_digest being None on a row that never stored one until its next draft write, so a list tells a never-published method, one whose draft matches its latest version and one whose draft is ahead apart without reading each method. list_methods and iterate_methods take published: bool | None, sent as published=true or published=false only when given.
• The run history's created_by and status filters: list_runs and iterate_runs take created_by: Literal["me"] | None, sent as created_by=me, which keeps the caller's own runs, and status: Sequence[RunStatus] | None, sent as one repeated status= parameter per status in the enum's order, which keeps the runs in any of them; an empty status or a name that is no RunStatus raises RequestArgumentError before any request, and a bare str raises TypeError. Under these filters, as under q and published on the methods list, a page can come back empty and still carry a next_cursor, and only a None cursor ends the list.

Changed

• iterate_runs follows the cursor through an empty page: it stopped at the first empty page, which under the new filters is not the end of the history, and now runs the same loop as iterate_methods, following the cursor until it is None or stops advancing and raising PagingNotTerminatingError past the same page ceiling.

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

Changed

• Both templates run on the SDK 0.39.0: @pipelex/sdk in the web app and pipelex-sdk in the CLI, with mthds 0.21.0 in the CLI, bumped from 0.35.1 and mthds 0.19.0. In both, a run start the API answers with a server error other than a 501 or a 503 saying starts are unavailable, or with a 408, or that loses its connection once sent, no longer offers a re-run, since the SDK now judges that such a start may have created a run and that a second attempt could pay for it twice. The CLI's read-out of a refused request now ends with a Retry: line even when the API sent no retryable of its own, since the SDK now always decides one, from the API's error domain or else from the status. mthds 0.21.0 reports MTHDS standard 5.0.0, which neither template reads, the SDK's other changes in between reach nothing either calls, and npm ls mthds still lists two copies in the web app, the form kernel's and the SDK's, as before this move.

The JavaScript starter, Pipelex/pipelex-starter-js

Changed

• The starter runs on @pipelex/sdk 0.39.0: bumped from 0.35.1. A run start the API answers with a server error other than a 501 or a 503 saying starts are unavailable, or with a 408, or that loses its connection once sent, no longer offers a re-run, since the SDK now judges that such a start may have created a run and that a second attempt could pay for it twice. The SDK's other changes in between reach nothing the starter calls, and npm ls mthds still lists two copies, the form kernel's and the SDK's, as before this move.

The Python starter, Pipelex/pipelex-starter-python

Changed

• The starter runs on pipelex-sdk 0.39.0, with mthds 0.21.0: bumped from 0.35.1 and mthds 0.19.0. A refused request read out in detail now ends with a Retry: line even when the API sent no retryable of its own, since the SDK now always decides one, from the API's error domain or else from the status. A run start the API answers with a server error other than a 501 or a 503 saying starts are unavailable, or with a 408, or that loses its connection once sent, no longer says that running it again may succeed, since the SDK now judges that such a start may have created a run and that a second attempt could pay for it twice. mthds 0.21.0 reports MTHDS standard 5.0.0, which nothing in the starter reads, and the SDK's other changes in between reach nothing it calls.