ci: install of cargo-audit errors out with stable-x86_64-pc-windows-msvc on ubuntu-latest — wire rust-toolchain channel for runners to stable-x86_64-unknown-linux-gnu

[Senorespecial]

Problem

The audit job in .github/workflows/ci.yml fails to install cargo-audit on ubuntu-latest. Job log (run id 27945553360, branch main):

cargo-audit is not installed, installing it now
[command]/home/runner/.cargo/bin/cargo install cargo-audit
error: target tuple in channel name 'stable-x86_64-pc-windows-msvc'
##[error]The process '/home/runner/.cargo/bin/cargo' failed with exit code 1

The error string stable-x86_64-pc-windows-msvc is the default Rust target triple on Windows hosts. Its appearance on an ubuntu-latest runner indicates that something in the toolchain configuration (rust-toolchain.toml or a CI-side env override) is forcing a Windows-flavoured channel name into cargo install's resolver on Linux.

The same run also fails the other three jobs (fmt · clippy · test, cargo-deny, gitleaks), so this is a systemic CI infra failure, not a recent workspace regression.

Why this is not related to "duplicate workspace keys"

Earlier sessions surfaced a "duplicate key workspace in table dependencies" cargo message. That was a $?-through-pipe misread (cargo check ... | tail -N; echo $? reported tail's exit code), not a real Cargo.toml parse failure. Verified clean now with proper PIPESTATUS exit propagation:

• cargo check --workspace on origin/main (clean working tree): exit 0.
• Same on feat/dashboard/sponsor-card (commit f81353e, PR feat(dashboard): add gas sponsorship status indicator to wallet cards (#14) #31): exit 0.
• Same on feat/gas-sponsorship/in-progress-feature (orphan dirty tree): exit 0.
• crates/api/Cargo.toml: grep -c '^stellar-base\.workspace' = 1, grep -c '^stellar-strkey\.workspace' = 1.

So the workspace itself is fine; the CI failure is purely the toolchain channel name.

What is wrong, specifically

The toolchain channel name resolves to a Windows triple on Linux. Likely:

• rust-toolchain.toml declares [toolchain] channel = "stable-x86_64-pc-windows-msvc" (verbatim triple), or
• the equivalent override on the runner (an env var RUSTUP_TOOLCHAIN, an Actions step setting a target triple, etc.).

On ubuntu-latest, the triple stable-x86_64-pc-windows-msvc cannot be materialized — rustup would need to download MSVC-linked build artifacts the runner can't host. Bash exits with the "target tuple in channel name" error.

Suggested fix

Pin rust-toolchain.toml to a portable channel so the triple resolves consistently per host:

[toolchain]
channel = "stable"

Replace any occurrence of the host-suffixed channel name in rust-toolchain.toml or in workflow env: RUSTUP_TOOLCHAIN: blocks. After that:

• Linux runners derive stable-x86_64-unknown-linux-gnu ✓
• macOS runners derive stable-x86_64-apple-darwin ✓
• Windows runners derive stable-x86_64-pc-windows-msvc ✓

If a specific MSRV is required, prefer channel = "1.84.1" (the version pinned in rust-toolchain.toml in the local clone) over a target-suffixed channel.

Acceptance criteria

• A fresh CI run on Octo-Protocol-org/Octo-Protocol:main produces audit job's conclusion == success.
• cargo install cargo-audit no longer errors with target tuple in channel name 'stable-x86_64-pc-windows-msvc' on Ubuntu / macOS / Windows runners.
• Other CI jobs (fmt · clippy · test, cargo-deny, gitleaks) also recover once the toolchain channel is portable.
• PR feat(dashboard): add gas sponsorship status indicator to wallet cards (#14) #31's CI status flips from "all red" to "all green" on the next run.

Suggested fix in PR form (sketch)

--- a/rust-toolchain.toml
+++ b/rust-toolchain.toml
@@
-[toolchain]
-channel = "stable-x86_64-pc-windows-msvc"
+[toolchain]
+channel = "stable"

 # or, if MSRV pin is needed
 # channel = "1.84.1"

One-line change; no manifest churn. Pair with --locked on every cargo invocation in .github/workflows/ci.yml so the lockfile parity gap from earlier sessions becomes a hard CI failure rather than silent regeneration.

References

• .github/workflows/ci.yml — pipeline (4 parallel jobs).
• Last CI run on main: id 27945553360 (status: failed; all 4 jobs failed).
• rust-toolchain.toml — channel pin (likely culprit).
• PR feat(dashboard): add gas sponsorship status indicator to wallet cards (#14) #31 (Senorespecial/Octo-Protocol -> Octo-Protocol-org/Octo-Protocol): feat(dashboard): add gas sponsorship status indicator to wallet cards (#14) #31 — its PR body note about an inherited cargo check --workspace failure is the same $? misread, not a real workspace issue. Worth updating alongside the toolchain fix.
• api: surface fees_spent_today_stroops in GET /v1/wallets/:id/sponsorship so dashboard consumption bar can render #32 — api: surface fees_spent_today_stroops (unrelated; sibling of feat(dashboard): add gas sponsorship status indicator to wallet cards (#14) #31).
• Earlier followup with full parity table in this conversation.

[Pavilion-devs]

I looked into this issue and confirmed the failure is caused by the repository-level rust-toolchain.toml using a host-suffixed Windows toolchain name, stable-x86_64-pc-windows-msvc, which makes even basic cargo/rustup commands fail on non-Windows runners.

My approach would be to update rust-toolchain.toml to use a portable channel, preferably 1.84.1 to match the project’s documented MSRV, or stable if the maintainers prefer floating stable. I would also check the CI workflow for any duplicate RUSTUP_TOOLCHAIN overrides, then rerun the audit, deny, fmt/clippy/test, and gitleaks jobs to confirm the whole pipeline recovers without touching unrelated manifests or lockfiles.

[Menjay7]

Hi! I came across this issue and would love to work on it. I have experience with similar tasks and I'm confident I can investigate, implement a clean solution, and thoroughly test it before submitting a PR. If the issue is still open, I would appreciate it if you could assign it to me. Thank you!

[happyboy24]

CAN I WORK ON THIS PLEASE