Repository navigation
Conversation
axios decodes a response body as UTF-8 text unless responseType says otherwise, so every jar written since the request -> axios switch is corrupt (~1.8x larger, "zip END header not found" in the JVM). Request an arraybuffer instead. A failed request (e.g. 404) went through .catch() and then into .then() with an undefined response, so `res.data` threw an unhandled rejection that crashed the process before the callback ran. Report it as "download failed for <url> [status: <code>]", as the request-based version did. Tests: jars resolved for ormlite-jdbc must match Maven Central's .sha1, and a missing artifact must come back through the callback. Co-Authored-By: Claude Opus 5.5 <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.
Problem
Since the switch from
requestto axios (0.1.3), every jar this package downloads is corrupt. axios decodes the response body as UTF-8 text unlessresponseTypesays otherwise, and the decoded string is what gets written to disk. Each jar comes out about 1.8x larger and fails to open:unzip -trejects it, and the JVM reportszip END header not found.A second bug in the same block: when a request fails (404, network error), the code runs
.catch()and then falls into.then()with an undefined response.res.datathen throws an unhandled rejection, which crashes the Node process before the caller's callback runs.Nobody in OSS has hit either bug, because
@cubejs-backend/jdbc-driverand@cubejs-backend/databricks-jdbc-driverdeclare nojava.dependencies, so this package never downloads anything for them. Cube Cloud's Microsoft Fabric driver does declare jars (mssql-jdbc, msal4j and their tree). It is still on the unmaintainednode-java-maven0.1.2 (which pullsrequest), and moving it to this fork is blocked on this fix.Fix
responseType: 'arraybuffer'and write the bytes as they are.download failed for <url> [status: <code>], the same message therequest-based version produced. The next step's callback runs outside the promise chain.Evidence
Resolving the Fabric driver's 31 jars from Maven Central into an empty local repository:
.sha1javaponSQLServerDrivernode-java-maven0.1.2 (request)@cubejs-backend/node-java-maven0.1.3zip END header not foundNew tests (both fail on
master, both pass here):should download jars byte-for-byte as published: resolvesormlite-jdbcand compares each jar's SHA-1 with the.sha1that Maven Central publishes.should report a missing artifact through the callback: resolves a non-existent artifact and expects the error in the callback instead of a process crash.The existing seven resolution tests still pass.
#2 targets the same corruption with a stream instead of an arraybuffer, but has no test. Either approach fixes the bytes. This PR also fixes the crash on a failed download.
🤖 Generated with Claude Code