ferrflow_release_size_mb is the only field the move to @ferrflow/doc (FerrLabs/FerrFlow-Cloud#929) could not carry, and dropping it is worse than it sounds. landing.component.ts falls back to ferrflow_binary_size_mb, the unstripped CI build, so the marketing page would show 8.0 MB where the real download is 3.4 MB.
The reason it cannot come from the package is ordering: embed-release-data.js runs during the release that publishes the package, and that release's own tarballs do not exist yet. The old six-hourly sync job worked around this by running hours later, when gh release view <tag> could see the assets.
FerrLabs/FerrFlow-Cloud#943 carries the last known value forward in sync-docs.mjs, which keeps the page correct but never refreshes the number.
The clean fix is on the producer side: embed-release-data.js embeds the previous release's linux-x64 tarball size, which is knowable at that moment. It lags by one version, but tarball size moves slowly and one version behind is far closer than an unstripped build. gh release view --json assets on the latest published tag is enough, and the release job already has a token with the read it needs.
Worth checking while implementing: whether ferrflow_binary_size_mb deserves to stay a fallback at all, given it is 2.4x off and silently produces a wrong marketing claim when the real value is missing. Failing loudly, or omitting the stat, may be better than a number nobody can tell is wrong.
ferrflow_release_size_mbis the only field the move to@ferrflow/doc(FerrLabs/FerrFlow-Cloud#929) could not carry, and dropping it is worse than it sounds.landing.component.tsfalls back toferrflow_binary_size_mb, the unstripped CI build, so the marketing page would show 8.0 MB where the real download is 3.4 MB.The reason it cannot come from the package is ordering:
embed-release-data.jsruns during the release that publishes the package, and that release's own tarballs do not exist yet. The old six-hourly sync job worked around this by running hours later, whengh release view <tag>could see the assets.FerrLabs/FerrFlow-Cloud#943 carries the last known value forward in
sync-docs.mjs, which keeps the page correct but never refreshes the number.The clean fix is on the producer side:
embed-release-data.jsembeds the previous release's linux-x64 tarball size, which is knowable at that moment. It lags by one version, but tarball size moves slowly and one version behind is far closer than an unstripped build.gh release view --json assetson the latest published tag is enough, and the release job already has a token with the read it needs.Worth checking while implementing: whether
ferrflow_binary_size_mbdeserves to stay a fallback at all, given it is 2.4x off and silently produces a wrong marketing claim when the real value is missing. Failing loudly, or omitting the stat, may be better than a number nobody can tell is wrong.