fix(ci): build compile-smoke's ext wrappers with the stdlib archive

[proggeramlug]

compile-smoke failed on release candidate 83754818ea with one compile error out of 1348 (1347 passed, 67 skipped):

test_issue_414_mysql_query_params
Error: the wrapper archive(s) below bundle a DIFFERENT tokio compilation
than the stdlib archive they would be linked with
  libperry_stdlib.a      bundles tokio-e69c74b77ea3bbaf
  libperry_ext_mysql2.a  bundles tokio-aa3a849219b7b42b

This is a job-configuration bug, not a product bug — and the guard is doing its job. Two tokio compilations in one binary mean two independent runtime::context::CONTEXT thread-locals, and perry-stdlib's runtime then reports there is no reactor running, must be called from the context of a Tokio 1.x runtime (#507, #7629). Refusing the link is the correct outcome; the mistake is upstream.

The job named only perry, perry-runtime, perry-stdlib and the two -static wrappers, so perry-ext-mysql2 was built by a separate invocation with its own feature unification. The fix names the ext wrappers in the same cargo build, which is what makes cargo unify tokio across them — exactly what the doc-tests job already does (-p perry-ext-ioredis -p perry-ext-mongodb -p perry-ext-mysql2 -p perry-ext-pg -p perry-ext-nodemailer). This adopts that same set rather than only mysql2, since any of them can hit the same class.

Why this went unnoticed

compile-smoke was cancelled on every prior release candidate, so this is the first verdict it has produced. It was one of six jobs with no result on any candidate; two have now reported and both were configuration issues rather than product defects (the other, parity (10), was a stale suppression — #9286).

The error message deserves credit: it names both tokio hashes, explains the runtime consequence, and prints the exact fix. That is what made this a five-minute diagnosis.

Summary by CodeRabbit

• Bug Fixes

  • Improved compile-smoke validation for database, caching, and email integrations.
  • Prevented build failures caused by incompatible runtime components being bundled together.
  • Avoided potential “no reactor running” errors during compiled application execution.

• Documentation

  • Added a changelog entry describing the improved extension build process.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 2380be30-de04-434d-bf5c-cdf418e16519

📥 Commits

Reviewing files that changed from the base of the PR and between 6d08afc and bf1d62e.

📒 Files selected for processing (2)

• .github/workflows/test.yml
• changelog.d/9290-compile-smoke-ext.md

Included review availability: Your plan provides up to 8 included reviews per hour; 5 remain after this review.

---

📝 Walkthrough

Walkthrough

The compile-smoke workflow now builds five extension wrapper crates with the stdlib archive in one Cargo invocation. A changelog entry documents the change and the related Tokio runtime issue.

Changes

Compile-smoke extension build

Layer / File(s)	Summary
Shared extension and stdlib build .github/workflows/test.yml, changelog.d/9290-compile-smoke-ext.md	The workflow builds five extension wrappers with the stdlib archive. The changelog documents the shared Cargo invocation and the related runtime error.

Estimated code review effort: 2 (Simple) | ~10 minutes

Merge Risk: ⚪ Minimal · up to bf1d6

The change updates the compile-smoke build to compile extension wrappers with the standard library archive, preventing a known CI configuration failure. No actionable merge-blocking risk remains beyond normal checks and review.

Suggested reviewers: jdalton, thehypnoo

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description gives strong technical context and explains the cause and fix, but it does not follow the required template. It omits the Summary, Changes, Related issue, Test plan, Screenshots / outp…	Rewrite the description using the repository template. Add the required section headings, list the concrete changes, state the related issue or use "n/a", document verification steps and results, and complete the checklist.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly identifies the CI job and the primary fix: building compile-smoke extension wrappers with the stdlib archive.

Full details: Docstring Coverage

Explanation

No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (2 skipped: 2 unsupported.)

Full details: Description check

Explanation

The description gives strong technical context and explains the cause and fix, but it does not follow the required template. It omits the Summary, Changes, Related issue, Test plan, Screenshots / output, and Checklist sections.

• Fix all pre-merge checks with AI

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/compile-smoke-ext-unification

---

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.}

[proggeramlug]

Merged.

The diagnosis is right and it's a trap I've hit from the other side: cargo unifies features per invocation, so building the ext wrappers separately from the stdlib archive gives each its own tokio compilation — two runtime::context::CONTEXT thread-locals, and the "no reactor running" panic downstream. Keeping the -p set identical across the whole set is the fix, and it generalises past CI: the same rule applies to any A/B or bisect, where dropping even -p perry between hops silently changes unification and makes the two arms incomparable.

Verified the specifics rather than the description:

• test.yml still parses.
• The doc-tests job at line 3626 already builds exactly this ext set in one invocation, so this brings compile-smoke in line with an existing precedent rather than inventing one.
• The refusal message quoted in the comment is real — crates/perry/src/commands/compile/shared_tokio.rs:312. That matters: the link failure is a deliberate guard catching a genuine mismatch, not a spurious error to be worked around. Fixing the build set is the correct response; suppressing the check would have been the wrong one.

The comment naming #507 and #7629 and the concrete symptom (test_issue_414_mysql_query_params) is what makes this maintainable — the next person to trim that -p list for build time will see why it can't be trimmed.

Worth noting alongside the "masked for weeks by continue-on-error" note already in that block: this is the second failure mode in the same step within a few lines of comment, and both were invisible rather than red. A step that cannot fail and a step that fails for a reason nobody reads are the same problem.