npm publish returns E404 on PUT /@rainlanguage%2ffloat, so @rainlanguage/float
has not been published since 2025-12-01. Solidity is unaffected and is being released
first; this issue exists so the npm side is tracked rather than carried in someone's head.
This isolates the diagnosis that rain.math.float.deploy#1 records as "exact error not yet
isolated from the CI log".
What the evidence rules out
- Not secret scoping.
NPM_PUBLISH_PRIVATE_TOKEN is visible to this repo, checked via
the org-secrets API, not inferred from secrets: inherit.
- Not the job's environment. The crates.io publish in the same job succeeds —
rain-math-float v0.1.11 published from here.
- Not a version conflict. No
0.0.x version of @rainlanguage/float was ever
published; the registry still holds 0.0.0-alpha.40. There is nothing to collide with.
E404 on a PUT to a scoped package name is what npm returns for a token that cannot write
that package, rather than for a package that does not exist. So this is the token's
validity or its permissions on @rainlanguage/float.
Two directions
- Refresh the token's access to
@rainlanguage/float and re-run. Smallest change,
and it leaves the failure mode in place for next time the token rotates.
- Move
rainix-autopublish onto npm OIDC trusted publishing. rainlanguage/raindex
has already migrated and publishes fine; the rainix-autopublish path still uses the
token. This removes the class of failure rather than the instance, and there is a
working in-org precedent to copy.
Direction 2 is a change to rainix and affects every consumer of that workflow, so it is a
decision rather than a fix to apply here.
Related
The version creep this failure produced — package.json at 0.0.13 with nothing
published at any 0.0.x — is not caused by the E404 itself. rainix-autopublish pushes
the bump before it publishes, so every failed run advances the number permanently. That
ordering is tracked separately in rainlanguage/rainix.
npm publishreturns E404 onPUT /@rainlanguage%2ffloat, so@rainlanguage/floathas not been published since 2025-12-01. Solidity is unaffected and is being released
first; this issue exists so the npm side is tracked rather than carried in someone's head.
This isolates the diagnosis that rain.math.float.deploy#1 records as "exact error not yet
isolated from the CI log".
What the evidence rules out
NPM_PUBLISH_PRIVATE_TOKENis visible to this repo, checked viathe org-secrets API, not inferred from
secrets: inherit.rain-math-floatv0.1.11 published from here.0.0.xversion of@rainlanguage/floatwas everpublished; the registry still holds
0.0.0-alpha.40. There is nothing to collide with.E404 on a
PUTto a scoped package name is what npm returns for a token that cannot writethat package, rather than for a package that does not exist. So this is the token's
validity or its permissions on
@rainlanguage/float.Two directions
@rainlanguage/floatand re-run. Smallest change,and it leaves the failure mode in place for next time the token rotates.
rainix-autopublishonto npm OIDC trusted publishing.rainlanguage/raindexhas already migrated and publishes fine; the
rainix-autopublishpath still uses thetoken. This removes the class of failure rather than the instance, and there is a
working in-org precedent to copy.
Direction 2 is a change to rainix and affects every consumer of that workflow, so it is a
decision rather than a fix to apply here.
Related
The version creep this failure produced —
package.jsonat0.0.13with nothingpublished at any
0.0.x— is not caused by the E404 itself.rainix-autopublishpushesthe bump before it publishes, so every failed run advances the number permanently. That
ordering is tracked separately in rainlanguage/rainix.