ci: publish relayfile-sdk Python SDK to PyPI

[khaliqgant]

Adapts relaycast's publish-python.yml for the relayfile Python SDK so we can ship relayfile-sdk to PyPI the same way.

What

• New .github/workflows/publish-python.yml — workflow_dispatch with version-bump choice (patch/minor/major/pre*), optional custom_version, and dry_run.
• Builds + tests with uv, runs twine check, publishes via PyPI trusted publishing (id-token), then commits the bump, tags sdk-python-v<version>, and cuts a GitHub Release.
• Renames the package to relayfile-sdk (import namespace stays relayfile).
• Commits a uv.lock (the workflow runs uv sync --locked) and adds a README install section.

Mirrors relaycast except the relayfile SDK has no SDK_VERSION constant, so the client-version sync step is dropped.

Before first publish

PyPI trusted publishing must be configured for the new relayfile-sdk project (a pending publisher: this repo, workflow publish-python.yml, env if any). The first dispatch will fail at the publish step until that exists. Run with dry_run: true first to validate build/test.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

@khaliqgant, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 53 minutes and 12 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 084a5425-783d-41ab-a63a-190bc4e44368

📥 Commits

Reviewing files that changed from the base of the PR and between 7104345 and 101a28b.

⛔ Files ignored due to path filters (1)

• packages/sdk/python/uv.lock is excluded by !**/*.lock

📒 Files selected for processing (3)

• .github/workflows/publish-python.yml
• packages/sdk/python/README.md
• packages/sdk/python/pyproject.toml

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch ci/publish-python-sdk

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[gemini-code-assist]

Code Review

This pull request renames the Python SDK package from relayfile to relayfile-sdk in pyproject.toml, updates the README.md with installation instructions for the renamed package, and adds a uv.lock file to lock project dependencies. There are no review comments, and I have no feedback to provide.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[github-actions]

Relayfile Eval Review

Run: .relayfile/evals/runs/2026-06-24T13-50-26-212Z-HEAD-provider
Mode: provider
Git SHA: 0d8cd19

Passed: 4 | Needs human: 0 | Reviewable: 0 | Missing output: 0 | Failed: 0 | Skipped: 0

Human Review Cases

No reviewable human-review cases captured Relayfile output.

[agent-relay-code]

⚠️ pr-reviewer did not push — the PR branch advanced during the review, so fixes were withheld to avoid overwriting newer commits. Re-trigger the review once the branch settles. The notes below are advisory and were not pushed.

PR Review: #1198 — fix(cli): retry inbound webhook auth from local broker

Summary

This PR adds an auth fallback to the three inbound-webhook CLI commands (create-inbound, list-inbound, delete-inbound). When the SDK call fails with Invalid API key or No workspace key found, the command retries once using the workspace key pulled from the running project broker's session — unless the user passed an explicit --workspace-key. It introduces runInboundWebhookOperation, resolveLocalBrokerWorkspaceKey, and withIntegrationDefaults, extends IntegrationCommandDependencies, adds two tests, and a changelog entry.

The change is well-scoped, fail-safe, and dependency-injected for testing. I made no code edits — nothing mechanical was needed and the logic is sound.

Verification (run against current checkout)

• Typecheck (CI path): built config, cloud, utils, policy, sdk, harness-driver, harnesses, fleet, then tsc --noEmit in packages/cli — passed, 0 errors.
• Tests: vitest run packages/cli/src/cli/commands/relaycast-groups.test.ts — 11/11 passed, including both new tests (retry-on-invalid-auth and no-retry-with-explicit-key).
• Lint: eslint src/cli/commands/integration.ts — clean.
• Prettier: integration.ts, relaycast-groups.test.ts, CHANGELOG.md — all formatted.
• API surfaces confirmed: HarnessDriverClient.connect/getSession/disconnect, SessionInfo.workspace_key, AgentRelayAgent.webhooks.{createInbound,list,delete}, SdkClientOptions.workspaceKey, getProjectPaths().projectRoot — all match usage.
• Error-string match confirmed: sdk-client.ts:31 throws "No workspace key found. ...", matched by /no workspace key found/i; RELAY_API_KEY is a real recognized env var (sdk-client.ts:27), so the changelog wording is accurate.

Findings

No blocking issues. The retry logic is fail-safe: on the second failure (or no local key), the original/new error propagates through runSdk, which calls deps.error() + deps.exit(1). No fail-closed → fail-open conversion; no fabricated success path. Explicit --workspace-key correctly suppresses retry (integration.ts:60).

Minor observations (non-blocking, no change made):

• resolveLocalBrokerWorkspaceKey swallows all broker-connection errors and returns undefined (integration.ts:25), which is the intended "best-effort fallback" behavior — on failure the original SDK error is rethrown, so the user still sees the real cause.
• list-inbound/delete-inbound now also retry on the same auth errors; this is consistent with create-inbound and matches the changelog. Acceptable.

Addressed comments

• No bot or human review comments were present in the harness inputs (.workforce/ contains only diff/context/changed-files; the comment seed files were empty). Nothing to address or validate as stale.

Advisory Notes

• None. The change stays within the PR's stated purpose (inbound webhook local-auth fallback); no unrelated refactors observed or warranted.

The PR builds, typechecks, lints, and tests green against the current checkout, and the changed logic is correct and fail-safe. I cannot confirm the live CI run status or merge-conflict/mergeable state from this sandbox, and those are required gates before handing back to a human, so I am not printing READY.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 101a28b1d8

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Tag the release before uploading to PyPI

In the main non-dry-run path, this upload runs before the Commit and tag step below. If the subsequent git push, tag push, or release creation fails, the PyPI version has already been published; PyPI release files are not reusable, so rerunning the workflow with the same version will fail before it can create the missing commit/tag. Please commit/tag the version bump before the upload, or publish from a tag-triggered workflow.

Useful? React with 👍 / 👎.

[agent-relay-code]

⚠️ pr-reviewer did not push — the PR branch advanced during the review, so fixes were withheld to avoid overwriting newer commits. Re-trigger the review once the branch settles. The notes below are advisory and were not pushed.

PR Review: Generalize integration auth fallback for local broker workflows

Summary of changes

The PR makes agent-relay integration webhook|subscription commands retry once with the running project broker's workspace key (and Relaycast base URL) after an SDK auth failure (Invalid API key, Invalid workspace key, no workspace key found, unauthorized). It generalizes a previously inbound-only fallback to all webhook/subscription operations, and threads relay_base_url from the broker through /api/session so retries hit the correct backend.

Touched areas:

• packages/cli/src/cli/commands/integration.ts — new runIntegrationOperation retry wrapper + helpers.
• crates/broker/src/listen_api.rs, crates/broker/src/runtime/init.rs — add relay_base_url to ListenApiConfig/ListenApiState and /api/session JSON.
• packages/harness-driver/src/client.ts — add relay_base_url? to SessionInfo.
• Tests, CHANGELOG.md, package-lock.json (9.0.1 → 9.1.0), trajectory records.

Verification (run against current checkout)

• npm ci — installed cleanly.
• npm run typecheck (builds all workspace deps + tsc --noEmit on CLI) — EXIT=0.
• npx vitest run packages/cli/src/cli/commands/relaycast-groups.test.ts — 12 passed, including the 3 new auth-fallback tests.
• Rust: cargo is not available in this sandbox, so I could not compile the broker. The Rust change is additive (one Option<String> struct field) with both ListenApiConfig literal constructors (runtime/init.rs:286, listen_api.rs:2551) and the /api/session serializer + test assertion updated; http_base is in scope at init.rs:197. I traced all ListenApiConfig constructors and relay_base_url references — no missed call sites — but I have not independently confirmed cargo build.

Impact tracing (beyond changed files)

• Data path is consistent end-to-end: broker /api/session emits relay_base_url → getSession() (harness-driver/src/client.ts:404) does a raw request<SessionInfo> with no Zod stripping → CLI resolveLocalBrokerRelayOptions reads session.relay_base_url.
• SdkClientOptions (sdk-client.ts:6) already has workspaceKey/baseUrl, so localRetryOptions is type-correct.
• connectProjectBrokerClient returns a HarnessDriverClient with getSession/disconnect — matches the narrowed inline type used in integration.ts.
• Retry is fail-safe: when the retry path doesn't apply (explicit --workspace-key, non-auth error, or no local options), the original error is rethrown — no error swallowing, no fail-open behavior. Delete/mutating ops only retry after a pre-execution auth failure, so no double-mutation risk.

Addressed comments

• CodeRabbit (per trajectory traj_ipdlvxuqj2b0): shorten PR 1198 changelog entry — stale; already handled by commit 8b4cf7a. The [Unreleased] > Fixed entry (CHANGELOG.md) is now a single impact-first bullet with no implementation detail.
• PR feedback (per trajectory traj_v96vk8uaesyw): brittle auth matching / inbound-only fallback / wrong-backend retry — stale; already handled by commits f15b38c and earlier on this branch. Verified in current checkout: shouldRetryWithLocalWorkspaceKey (integration.ts:65) matches the broadened set, runIntegrationOperation wraps all webhook+subscription ops, and localRetryOptions carries baseUrl so the broker key targets the right backend.

No bot/reviewer comment files were provided in .workforce/ beyond the diff and context.json (which contains no review threads), so the above are the comments referenced by the branch's own trajectory records.

Advisory Notes

• None requiring code changes. Minor non-blocking observation: runIntegrationOperation constructs the SDK options once and reuses them on retry, which is correct; no action needed.

Auto-applied fixes

None. The PR is mechanically clean (Prettier-formatted, imports ordered, no typos). All logic is behavior-affecting, so per policy I left it unchanged and only verified.

Status

The PR typechecks and its tests pass in this checkout. I could not run the Rust broker build (no cargo in sandbox) or confirm CI check status / mergeability — those are outside what I can verify here. Because required checks (full CI incl. Rust build) are not confirmed-complete-and-green from my side, I am not declaring it human-ready.

[agent-relay-code]

ℹ️ pr-reviewer: review only — no file changes were applied to the PR (nothing to commit after review). The notes below are advisory and were not pushed.

Review Summary — PR #337 (ci/publish-python-sdk)

This PR adds a workflow_dispatch GitHub Actions workflow to build, test, and publish the Python SDK to PyPI, renames the distribution from relayfile to relayfile-sdk, adds an install section to the README, and commits the previously-untracked uv.lock.

Scope is clean and self-contained. No application/runtime code is touched — no lifecycle, broker, dispatch, or digest paths are involved. The import namespace (src/relayfile) is intentionally unchanged, so the rename only affects the published distribution name, not consumers' import relayfile.

Verification (ran the workflow's exact sequence locally)

• uv lock → no changes to committed lockfile (consistent with pyproject.toml).
• uv sync --all-extras --locked → passed; editable install resolves as relayfile-sdk==0.2.0.
• uv run python -m pytest → 81 passed.
• uv build → built relayfile_sdk-0.2.0.tar.gz + wheel.
• uvx twine check dist/* → PASSED for both artifacts.
• Wheel inspection confirms it ships the relayfile/ import package — matches the README's "import namespace remains relayfile" claim.

Cleaned up all generated artifacts (dist/, .venv/, egg-info); working tree is clean.

No files were edited. No mechanical fixes were needed (YAML, lockfile, and metadata are all clean).

Addressed comments

• Devin review comment BUG_..._0001 (.msd-autofix-findings, tsconfig test-exclusion): invalid for this PR — targets packages/relayfile-sdk/tsconfig.json (the TypeScript SDK) and references pull/6, neither of which this PR touches. Stale/unrelated; left unchanged.
• Devin review comment BUG_..._0002 (.msd-autofix-findings, BulkWriteResponse.correlationId): invalid for this PR — targets packages/relayfile-sdk/src/types.ts (TypeScript SDK), not in this diff. Stale/unrelated; left unchanged.

Advisory Notes

These are out of scope for this PR (they touch unrelated files or are operational), so I left the code unchanged:

• docs/sdk-improvements.md:60 still shows pip install relayfile (old dist name). Not in this PR's diff; updating it here would be an unrelated doc edit. Worth a follow-up so docs match the new relayfile-sdk name.
• packages/sdk/python/README.md:1 heading is still # relayfile. Cosmetic only (the install command and namespace note below it are correct). Left as-is to avoid a non-essential edit.
• PyPI Trusted Publishing prerequisite: pypa/gh-action-pypi-publish runs with id-token: write and no password, so it depends on the relayfile-sdk PyPI project having a Trusted Publisher configured for this workflow. If that's not set up, the first real (non-dry-run) publish on main will fail. Operational setup, not a code defect — flagging for the maintainer.
• Branch gating is fail-closed and correct: version-bump always runs, but publish/commit/tag/release are gated on github.ref == 'refs/heads/main' and dry_run != 'true', so a non-main or dry-run dispatch builds/tests only and skips publishing. No safety-default regression.

The PR's only CI exposure on a pull request is YAML validity (the existing ci.yml has no Python job; the new workflow is dispatch-only). I cannot confirm the live PR's check/mergeable status from inside the sandbox, so I'm not declaring it human-ready.