Skip to content

Qualify published whole-history and workflow-list pagination - #330

Merged
rmcdaniel merged 2 commits into
mainfrom
sdk-python/247-published-pagination
Nov 14, 2026
Merged

rmcdaniel merged 2 commits into
mainfrom
sdk-python/247-published-pagination

Conversation

@rmcdaniel

@rmcdaniel rmcdaniel commented Nov 14, 2026 •

Copy link
Copy Markdown
Member

Python's whole-history and workflow-list iterators already ship in the published package, but shared #247 still lacks Python's installed multi-page proof. This adds one manual registry-only pagination case to the maintained acceptance runner. It changes no SDK runtime source or release metadata.

The fixed published tuple seeds five cancelled matches and three filter controls through public start/cancel calls. It compares three filtered list pages and one-event history pages with independent quiescent single-page reads, checks every opaque continuation and canonical namespace/run/filter, exercises handle history, early close, resume and namespace-change refusal, and retains the actual pages. No Worker is required.

The existing complete wheel lock, captured no-site entry, installed wheel/RECORD inventory, closed two-container internal network and ID-bound cleanup remain in force. The manual job defaults off. Source review, current checks, integration and exact accepted-main readback precede selection of one bounded installed invocation. Existing set-aside retry-cap and held timer/SQLite cells are unchanged.

Validation so far: 215 focused iterator/controller/consumer/entry/inventory tests pass; Ruff and mypy pass. The complete fixture also runs through native-shaped MockTransport responses, with foreign response-run controls. The 56 fixture/iterator controls pass again importing the exact 2.17.2 registry wheel directly (mock-only evidence). The new page-evidence controls reject cursor/run/filter drift, omitted/duplicate/reordered events and unread continuation tails. No installed pagination cell has run.

Tracks durable-workflow/.github#247.

@sonarqubecloud

Copy link
Copy Markdown

@rmcdaniel

Copy link
Copy Markdown
Member Author

Security source/case/invocation review: PASS, scoped to exact head 51811a7868a65326a2c42c4472ce90dbe50b7c94.

I reviewed the complete seven-file delta against base 0f281d748..., the published 2.17.2 tuple/profile reuse, the manual-only workflow wiring, the pagination case, and the complete native-shaped evidence fixture. The case is closed over the five selected workflow/run identities; foreign workflow/run responses refuse; the three negative-filter records are proved absent; page sizes/tokens and the 2→3 page transition are exact; history paging is bound to the selected run; namespace changes refuse; early-close/resume semantics are tested without treating an unread item in the current page as resumable. Server 2.8 source confirms that the public failed visibility bucket includes cancelled terminal executions, so the cancellation setup and filter are consistent.

The existing closed two-container profile, 15-wheel lock, SDK/wheel/RECORD inventory, identity-only cleanup, and effect bounds are reused without widening. No Worker or application payload is introduced, and no SDK/runtime source changes are made.

Independent focused verification in a fresh temporary environment: 38 passed for tests/test_published_pagination_evidence.py plus tests/test_activity_acceptance_consumer.py. Current exact-head checks are terminal green; the effectful pagination job is skipped as intended on an ordinary PR run.

This is a source/case/invocation verdict only. It does not select a dispatch or qualify installed/public execution evidence.

@rmcdaniel
rmcdaniel merged commit 949d38b into main Nov 14, 2026
24 checks passed
@rmcdaniel
rmcdaniel deleted the sdk-python/247-published-pagination branch November 14, 2026 11:07
@rmcdaniel

Copy link
Copy Markdown
Member Author

Owner selects one ordinary registry pagination invocation after exact integration. Merge 949d38bb59aa7221f1e05f1309f3a6f0f53c8d96 / tree 18cd4d44b478eb15f255e88e91e254b80e05fbdd equals reviewed head 51811a7's tree; its parents are accepted 0f281d7 and 51811a7. All 24 head checks and all 22 accepted-main checks are terminal (manual jobs intentionally skipped). Independent source/case/invocation PASS applies to that exact tree. The merged topic branch is independently absent.

Invocation: gh workflow run ci.yml --ref main -f published_pagination=true -f published_activity_acceptance=false -f published_timer_redrive=false -f activity_retry_cap=false -f cooperative_qualification=false. Main currently resolves to 949d38b. The fixed scenario is pagination, artifact source is the normal registry, case SHA256 06dee290b08f04e165d884b1c110053f6cf4f77bc8d781cd119428bd99ab9c21, tuple SHA256 fa189ed91c9f2a36a8fe2f91901f0f35b8af062bcc79a87a124afedad126828d, and complete 15-wheel lock SHA256 6c6444e9e18740acfadfaea5152ac310c46c275cd3641c9390a0f968e137087e.

The selected published tuple remains SDK 2.17.2 wheel 7dc77d38…, native Server 3.9.2 index 8ffcdb2a… / amd64 child 813c9337… / source 5614274d…, and Python 3.12.16 index 935c3c5b… / amd64 child 0f086103…, as the committed fixture fully specifies. The unchanged closed internal two-container profile has one CPU/one GiB/256 PIDs per role, no host mounts or published ports, fixed synthetic auth, fresh hash-locked installation and before/after wheel/RECORD authority. The case bounds itself at 60 seconds; controller workload is bounded at six minutes, with ID/label-bound independent cleanup and seven-day artifact retention. No Worker is used.

This selects no package publication, retry-cap, timer-redrive, SQLite/helper or other set-aside cell. A failure remains NONPASS; no automatic unchanged repeat is selected. Installed result and independent evidence review remain pending this invocation.

@rmcdaniel

Copy link
Copy Markdown
Member Author

The selected first pagination invocation is runner-blocked/NONPASS, run 43589090161, job 132429911711, exact source 949d38bb59aa7221f1e05f1309f3a6f0f53c8d96. Original artifact 14111717561 has raw ZIP SHA256 6dd806e36da714a740061cd02853fbe9b7358a15a10aa925fae7f0f8b383ea6a and seven-day retention.

The retained JUnit reports the single installed case passed (0.235 seconds): three filtered list pages and four one-event history pages, resume/early-close/namespace controls. Before/after SDK authority files are byte-identical. Those observations do not qualify the cell: the controller subsequently raised ValueError: terminal result exceeded its bound, and the pre-reserved result.json is zero bytes. Cleanup was invoked before final serialization in the captured source, but its independent terminal absence verdict is not retained and is therefore unqualified.

The concrete source defect is oversized readiness inventory embedded in the bounded terminal receipt. I am preparing a narrow source successor that retains complete readiness evidence separately with a digest/size reference, keeps the 128 KiB terminal bound, and writes a bounded NONPASS receipt even if a future report exceeds it. Source tests/review/current integration precede selection of any fresh invocation. No unchanged retry, SDK release, authentication cause, or broader installed success is inferred.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant