Run the S3 suite against RustFS 1.0.0 and SeaweedFS 4.47

[kisielewski]

RustFS published its first stable release on 2026-09-16, and SeaweedFS is two releases on from the pin, so both move to the newest stable: rustfs/rustfs:1.0.0-rc.5 to 1.0.0, and chrislusf/seaweedfs:4.45 to 4.47. The RustFS tag is written in the two places docs/RELEASE.md warns about — S3BlobStoreTests.cs and the development compose file — and both copies moved.

What was measured, 2026-09-20

S3 conformance suite, RustFS 1.0.0	16 of 16, nothing skipped
S3 conformance suite, SeaweedFS 4.47	15 passed, 1 skipped — the encryption item, by EncryptionCapableFactAttribute
Full suite	989 passed, 0 failed, 0 skipped
Build with -warnaserror	0 warnings
The development stack, as CI's compose job runs it	healthy; /api/v1/health answers ok and names no part of the storage; /health is 404; aj-admin storage status reachable with its smoke test passed; migrate, a refused second migrate (409) and cancel all as that job expects
An upgrade over bytes that already exist	an object written under 1.0.0-rc.5 is readable under 1.0.0 on the same volume, and the upgraded directory accepts fresh writes

That last row is the one nobody would have noticed going wrong. CI and a fresh clone both start on an empty volume, so neither would have caught a data directory the new version could not read, while every developer carrying an algojudge_dev_objects volume would have.

SeaweedFS still agrees to encrypt and then stops working, and that was the claim worth re-measuring rather than carrying forward. With the skip lifted, 4.47 reproduces it exactly: PutBucketEncryption is accepted and the next write fails with We encountered an internal error, while the write the fixture makes before the call succeeds. The skip stays, and its runtime message now cites 4.43, 4.45 and 4.47 instead of two versions nobody runs.

Prose that had stopped being true

README.md said There is still no stable 1.0.0, and the development compose justified the pin by calling the release-candidate form the newest thing this image publishes as a version. Both were arguments from the absence of a stable release, and both are gone.

docs/RELEASE.md loses the dated paragraph recording the 2026-09-07 bump. A runbook states what is true now, and the rule a release-day reader needs — a newer store is taken when the suite agrees on it, and left alone otherwise — is the paragraph directly above it.

The comment above the SeaweedFS pin kept a long account of two version differences that turned out to be ours rather than the image's. The lesson survives in two sentences; the measurements behind it are in CLAUDE.md, which is where they were already written down in full.

Not covered

The readiness figures in S3BlobStoreTests.cs — 2.1 s on 4.43, 3.1 s on 4.44 — were not re-taken on 4.47. They illustrate why ServingAsync retries the store's own health check rather than setting any threshold, and the suite is green either way.

Nothing here reaches an installation. The stores this suite starts are a test fixture and the development stack; an installation brings its own S3 endpoint, and AlgoJudge-Ops names no store product or version at all.