Fail clearly on empty downloads; friendlier create errors (#43) - #57
Merged
Conversation
Fail clearly on empty downloads; friendlier create errors (#43) Mohist creation surfaced two baffling messages. The tell was a checksum mismatch reporting got=e3b0c442… — the SHA-256 of ZERO bytes — i.e. the mirror returned a 200 with an empty body and the "corruption" error hid the real cause. The other, no-mohist-build, fires because the upstream API lists Minecraft versions that currently have no build (verified: 1.20.6 and 1.21.4 return "builds":[]). - net.ts downloadFile: after streaming, a 0-byte body is now a hard `empty-download: <url>` error (dest removed) *before* the checksum step, so an empty response never masquerades as a checksum mismatch. Guards every provider, not just Mohist. - CreateView: map short backend codes to human messages — no-*-build ("no build for this version, pick another"), empty-download, folder-exists, installer-args-not-found — instead of showing the raw code. Unknown codes still pass through. New en/tr strings. - WIZARD smoke: a local 0-byte HTTP 200 makes downloadFile throw empty-download (not a checksum error) and leave no partial file. Scope/honesty: this does NOT make Mohist downloads succeed where the upstream mirror is empty or a version has no build — it turns those failures into clear, actionable messages. The Mohist provider already matches the current v2 API (number/fileSha256/url verified live), so no field remapping was needed; a fallback-on-empty retry to originUrl is a possible future follow-up but is unverifiable from here. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> @
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #43. Part of the provider-reliability pass (#44).
Problem
Mohist creation surfaced two baffling messages:
Checksum mismatch (got e3b0c442…, expected 5ad74546…)—e3b0c442…is the SHA-256 of zero bytes, i.e. the mirror returned a 200 with an empty body and the "corruption" error hid the real cause.no-mohist-build— the upstream API lists Minecraft versions that currently have no build. Verified live:1.20.6and1.21.4both return"builds":[].Fix
net.ts downloadFile: after streaming, a 0-byte body is now a hardempty-download: <url>error (destination removed) before the checksum step, so an empty response never masquerades as a checksum mismatch. This guards every provider, not just Mohist.CreateView: map short backend codes to human messages —no-*-build("no build for this version, pick another"),empty-download,folder-exists,installer-args-not-found— instead of showing the raw code. Unknown codes still pass through. Newen/trstrings.MSMS_SMOKE_WIZARD: a throwaway local HTTP server returns a 0-byte 200;downloadFilemust throwempty-download(not a checksum error) and leave no partial file.Scope & honesty
This does not make Mohist downloads succeed where the upstream mirror serves an empty body or a version has no build — it turns those failures into clear, actionable messages. The Mohist provider already matches the current v2 API (
number/fileSha256/urlconfirmed against live responses), so no field remapping was needed. A fallback-on-empty retry tooriginUrlis a possible future follow-up but cannot be verified from this environment (direct jar downloads are unreachable here), so it is intentionally left out.Verify
typecheck,build— pass.MSMS_SMOKE_WIZARDPASS, including the newempty-download guardblock.mohistmc.com/api/v2responses; the actual jar transfer was not exercised here.🤖 Generated with Claude Code