feat: Share runs via Python SDK#667
Conversation
There was a problem hiding this comment.
Pull request overview
This PR aims to add “run sharing” capabilities to the Python SDK by introducing access-control resource wrappers (grants + share tokens), wiring them into the platform client, and exposing sharing workflows through the application service and CLI.
Changes:
- Added new access-control resource layer (
AccessGrant,ShareToken,ShareTokens) and newRunhelpers (list_share_grants,grant_access). - Added new application service + CLI commands under
run share ...to list/grant/revoke access and manage share tokens. - Regenerated codegen artifacts/docs for updated API parameters (e.g., grants relation filter, additional run filters, run organization_id field).
Reviewed changes
Copilot reviewed 8 out of 61 changed files in this pull request and generated 18 comments.
Show a summary per file
| File | Description |
|---|---|
src/aignostics/platform/resources/access.py |
New access-control resource models and share-token listing/creation logic. |
src/aignostics/platform/resources/runs.py |
Adds run-level grant listing/creation helpers with caching/retry integration. |
src/aignostics/platform/_client.py |
Exposes a share_tokens resource on Client. |
src/aignostics/application/_service.py |
Adds service methods for run sharing and token management. |
src/aignostics/application/_cli.py |
Adds run share ... CLI command group. |
tests/aignostics/platform/resources/access_test.py |
Unit tests for access resources. |
tests/aignostics/platform/resources/run_sharing_test.py |
Unit tests for run-sharing workflows (currently mismatched with implementation). |
codegen/in/openapi.json + codegen/out/** |
Codegen updates reflecting API spec changes. |
Codecov Report❌ Patch coverage is
|
3bbec8d to
1131c91
Compare
1131c91 to
fa0f3b9
Compare
fa0f3b9 to
c4e64be
Compare
ffa17dc to
ece8b91
Compare
The decorator was accidentally doubled in the code review suggestions commit, which would register the command twice and break CLI invocation. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…f share-status check ShareTokens.list(run_id=..., revoked=False) filters on the *token's* revoked flag, not the access grant's. After application_run_revoke_share_token revokes only the grant (not the token itself), the token still appears in share status, making the previous step-4 assertion always fail. Replace the share-status check with a second revoke attempt: the service raises NotFoundException (→ exit 2) when no active grant is found for the token on the run, which is the authoritative signal that the grant is gone. Also ignore run_dont_commit.py in pyrightconfig to keep local lint clean. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
f6b39f5 to
e6deccd
Compare
ShareTokens.list(run_id=..., revoked=False) filters on the token's own revoked flag. After application_run_revoke_share_token revokes the grant (not the token itself), the token still appeared in share status. Fix application_run_share_tokens to drive the list from active grants (Run.list_share_grants(subject_type=SHARE_TOKEN)) and resolve each grant's subject_id to a full ShareToken. This guarantees that only tokens with live grants appear in the output. Also extend the e2e test with a retry-wrapped share-status step that verifies the token is absent after revocation. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
e6deccd to
77e1eb8
Compare
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
64cd279 to
6ea4f1f
Compare
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
…-based filtering The service now cross-filters share tokens against active grants instead of relying on ShareTokens.list(run_id=...). Update the unit test to wire up the mock client (was missing mock_get_client.return_value), configure a matching grant on the mock run, and assert that list_share_grants is called with the correct arguments. Also restore run_dont_commit.py to pyrightconfig.json ignore list. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
|
In addition to the SPECs outlined in the CR, we should also update the CLI Interface section in specifications/SPEC-APPLICATION-SERVICE.md with a short summary of the new commands |
| console.print(f"Share token created for run '{run_id}'.") | ||
| console.print(f" Token ID : {token.share_token_id}") | ||
| console.print(f" Token : [bold]{token.share_token}[/bold]") | ||
| console.print(f" Expires : {expires}") | ||
| console.print("[yellow]Save the token value — it will not be shown again.[/yellow]") |
There was a problem hiding this comment.
How would this token be consumed at a later point in time?
aignostics application run describe [OPTIONS] RUN_ID --share-token <TOKEN>?
Could we improve user experience through the CLI, if we prepare copyable commands, when print is used?
| System shall enable run submitters and organization admins to grant read access to a specific application run to another authenticated | ||
| platform user or to all users belonging to a specified organization. The system shall list all active access grants | ||
| for a given run, including for each grant the subject type, subject identifier, relation, and creation metadata. | ||
| The system shall revoke any individual grant on demand, removing the associated access immediately. |
There was a problem hiding this comment.
Do you think we can generalize these software requirements? Instead of replicating the details of the API requirements.
E.g. "System shall enable run owners and organization admins to manage user and organization access for a given application run through the CLI"
| System shall enable run submitters and organization admins to create revocable share tokens with an optional expiry date | ||
| and to grant read access to a specific application run via such a token, allowing secure sharing with other platform | ||
| users. The system shall list all active share tokens for the authenticated user. The system shall list all grants | ||
| associated with a given share token. The system shall revoke a share token's grant on a specific run on demand. The | ||
| token secret shall be returned only at creation time and shall not be retrievable subsequently. |
There was a problem hiding this comment.
Similar to above:
E.g. "System shall enable run owners and organization admins to manage share tokens for a given application run through the CLI"
| self, | ||
| subject_type: SubjectType | None = None, | ||
| subject_id: str | None = None, | ||
| relation: list[GrantRelation] | None = None, |
There was a problem hiding this comment.
This filter is currently unreleased in PAPI Prod.
Do we need to sneak in a 1.6.1 release?



No description provided.