InvalidRange: The requested range is not satisfiable when disabledChunk: true

[vecerek]

Sometimes I'm getting the following error:

InvalidRange: The requested range is not satisfiable
    at throwDefaultError (/app/node_modules/@smithy/smithy-client/dist-cjs/default-error-handler.js:8:22)
    at /app/node_modules/@smithy/smithy-client/dist-cjs/default-error-handler.js:18:39
    at de_GetObjectCommandError (/app/node_modules/@aws-sdk/client-s3/dist-cjs/protocols/Aws_restXml.js:4330:20)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async /app/node_modules/@smithy/middleware-serde/dist-cjs/deserializerMiddleware.js:7:24
    at async /app/node_modules/@aws-sdk/middleware-signing/dist-cjs/awsAuthMiddleware.js:14:20
    at async /app/node_modules/@smithy/middleware-retry/dist-cjs/retryMiddleware.js:27:46
    at async /app/node_modules/@aws-sdk/middleware-flexible-checksums/dist-cjs/flexibleChecksumsMiddleware.js:58:20
    at async /app/node_modules/@aws-sdk/middleware-logger/dist-cjs/loggerMiddleware.js:7:26
    at async makeTokenizer (/app/node_modules/@tokenizer/s3/lib/index.js:18:22)
    at async fp_ts_1.taskEither.tryCatch._typename (/app/packages/asset-repos/dist/asset/util/file-type.js:21:25)

at async makeTokenizer (/app/node_modules/@tokenizer/s3/lib/index.js:18:22) points to this line. I'm not able to reproduce the error with a specific file. Once I can, I will update the issue.

Versions used:

library	version
@tokenizer/s3	0.2.3
@smithy/smithy-client	2.0.5

[johnf]

I get this with disabledChunked: false in the case where the file in S3 is empty.

I think the issue is at https://github.com/Borewit/tokenizer-s3/blob/master/lib/s3-request.ts#L48-L56
S3 throws an error due to the invalid range.

@Borewit I'm happy to do a PR if I could get some guidance. I'm not sure what makes the best sense.
I was thinking of returning {} on the catch, which would then be caught by https://github.com/Borewit/tokenizer-range/blob/master/lib/range-request-factory.ts#L56-L58 and at least throw a more meaningful error?

[Borewit]

Hi @johnf , thanks for looking into this. The best error messages usually generated at the place they occur. Caught exceptions can possibly at a bit of more complicated context information but should certainly not replace the original error message.

What would do you think be a more meaningful error?

I think the requested range and the file length would be interesting to add to the error, which could help to nail down this issue.

[vecerek]

Also, if you don't want to lose the original error, set the cause property on the wrapping error: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/cause.