rainix-autopublish publishes a library revision without noticing that the downstream repo that inlines it is many revisions behind
A library repo on this workflow patch-bumps on every content-changing merge. Its downstream consumers pin a Soldeer version in foundry.toml/soldeer.lock and inline it by versioned import prefix (<pkg>-<x.y.z>/src/...), and a deploy repo moves that pin only on a manual sol-v* tag. So the gap between what a library publishes and what the deployed contract actually embeds widens by default, and closes only when a human remembers. Nothing on either side goes red.
Live instance that prompted this: rainlanguage/rain.factory is at rain-factory 0.1.23; rainlanguage/rain.factory.deploy pins 0.1.9 (c1c2afd, 2026-08-20). The contract at 0xAb9741E6f843452D649FCa35899d8F9A36e7DcA8 on mainnet contains neither DelegatedImplementation() (0xe6f6d6de, the EIP-7702 rejection) nor CloneAddressOccupied(address) (0x134a0bbc), both of which the library head documents and implements. Filed there as rainlanguage/rain.factory.deploy#42; the source-side documentation scoping is rainlanguage/rain.factory#110.
This is not one repo's problem. Every library repo here with a downstream repo that pins it by version has the same hazard, which is why the detector belongs in this reusable and not in 38 copies of a repo-local workflow.
Proposed fix
Add a downstream-consumers: input to .github/workflows/rainix-autopublish.yaml — space-separated org/repo names, declared by the library caller alongside soldeer-package:
with:
soldeer-package: rain-factory
downstream-consumers: rainlanguage/rain.factory.deployAfter a successful Soldeer publish, for each named repo: read its soldeer.lock entry for inputs.soldeer-package, and compare the NORMALIZED content of the pinned revision against the revision just published. rainix-static soldeer-gate (rainix-static/src/soldeer_gate.rs) already does exactly this normalized published-zip comparison to decide whether to publish at all, so the drift check is the same comparison against a different baseline, not new machinery.
It must alert, never block. Failing the publish deadlocks: the library cannot release until the consumer bumps, the consumer cannot bump until the library releases, alternating merges leave main red on both. The alert should be an issue opened (or an existing open one updated) on the consumer repo naming the pinned version, the newly published version, and the normalized diff — and the publish job stays green.
Open question for whoever picks this up: whether the alert issue is opened on the consumer repo or the library repo. Consumer is where the bump work lives; library is where the run happens and has the token. Consumer seems right, and it needs a cross-repo token, which is the part that decides it.
🤖 Generated with Claude Code
rainix-autopublishpublishes a library revision without noticing that the downstream repo that inlines it is many revisions behindA library repo on this workflow patch-bumps on every content-changing merge. Its downstream consumers pin a Soldeer version in
foundry.toml/soldeer.lockand inline it by versioned import prefix (<pkg>-<x.y.z>/src/...), and a deploy repo moves that pin only on a manualsol-v*tag. So the gap between what a library publishes and what the deployed contract actually embeds widens by default, and closes only when a human remembers. Nothing on either side goes red.Live instance that prompted this: rainlanguage/rain.factory is at
rain-factory0.1.23; rainlanguage/rain.factory.deploy pins 0.1.9 (c1c2afd, 2026-08-20). The contract at0xAb9741E6f843452D649FCa35899d8F9A36e7DcA8on mainnet contains neitherDelegatedImplementation()(0xe6f6d6de, the EIP-7702 rejection) norCloneAddressOccupied(address)(0x134a0bbc), both of which the library head documents and implements. Filed there as rainlanguage/rain.factory.deploy#42; the source-side documentation scoping is rainlanguage/rain.factory#110.This is not one repo's problem. Every library repo here with a downstream repo that pins it by version has the same hazard, which is why the detector belongs in this reusable and not in 38 copies of a repo-local workflow.
Proposed fix
Add a
downstream-consumers:input to.github/workflows/rainix-autopublish.yaml— space-separatedorg/reponames, declared by the library caller alongsidesoldeer-package:After a successful Soldeer publish, for each named repo: read its
soldeer.lockentry forinputs.soldeer-package, and compare the NORMALIZED content of the pinned revision against the revision just published.rainix-static soldeer-gate(rainix-static/src/soldeer_gate.rs) already does exactly this normalized published-zip comparison to decide whether to publish at all, so the drift check is the same comparison against a different baseline, not new machinery.It must alert, never block. Failing the publish deadlocks: the library cannot release until the consumer bumps, the consumer cannot bump until the library releases, alternating merges leave main red on both. The alert should be an issue opened (or an existing open one updated) on the consumer repo naming the pinned version, the newly published version, and the normalized diff — and the publish job stays green.
Open question for whoever picks this up: whether the alert issue is opened on the consumer repo or the library repo. Consumer is where the bump work lives; library is where the run happens and has the token. Consumer seems right, and it needs a cross-repo token, which is the part that decides it.
🤖 Generated with Claude Code