When uploading a file using file.save(), we are encountering an error which is not handled by the underlying wrapper, and thus falls through the try/cach which wraps the await file.save() call.
Logs from node:
TypeError: Cannot read property 'reason' of null
at Object.RETRYABLE_ERR_FN_DEFAULT [as retryableErrorFn] (/app/node_modules/@google-cloud/storage/build/src/storage.js:92:40)
at Pumpify.<anonymous> (/app/node_modules/@google-cloud/storage/build/src/file.js:2937:51)
at Pumpify.emit (events.js:400:28)
at Pumpify.emit (domain.js:475:12)
at Pumpify.Duplexify._destroy (/app/node_modules/duplexify/index.js:195:15)
at /app/node_modules/duplexify/index.js:185:10
at processTicksAndRejections (internal/process/task_queues.js:77:11)
Looking into the code (JS), this is what I see:
file.js, line 2916 (approx in src: https://github.com/googleapis/nodejs-storage/blob/main/src/file.ts#L3737)
The save() async function creates a new promise, then basically creates a write stream. On an error, it will check if autoRetry is enabled, and if so, checks if the err is autoRetryable. So far so good.
storage.js, line 84 (approx in src: https://github.com/googleapis/nodejs-storage/blob/main/src/storage.ts#L260)
This default retry function assumes that the property reason exists on each item in the errors array, which as per the error stacktrace seems is not the case.
Since this is within the promise constructor function in file.js, it goes unhandled and reject is not called, which leads to this uncaught exception (my guess)
I am going to try and set the retry option to false for now, so that this default retry function would never run, and hopefully this wont be thrown, will report back later on how that goes. But I do believe the default function has a bug if it cannot handle this case. As to what causes this "weird error" where the object is null to be thrown, I've not dug that deep yet.
- OS: Nodejs Alpine image (v14.17)
- Node.js version: 14.17 (old LTS)
- npm version: 6.x
@google-cloud/storage version: 5.14.8
Steps to reproduce
- Not 100% of the time, but when some uploads fail using
await file.save()
When uploading a file using
file.save(), we are encountering an error which is not handled by the underlying wrapper, and thus falls through the try/cach which wraps theawait file.save()call.Logs from node:
Looking into the code (JS), this is what I see:
file.js, line 2916 (approx in src: https://github.com/googleapis/nodejs-storage/blob/main/src/file.ts#L3737)The
save()async function creates a new promise, then basically creates a write stream. On an error, it will check if autoRetry is enabled, and if so, checks if the err is autoRetryable. So far so good.storage.js, line 84 (approx in src: https://github.com/googleapis/nodejs-storage/blob/main/src/storage.ts#L260)This default retry function assumes that the property
reasonexists on each item in the errors array, which as per the error stacktrace seems is not the case.Since this is within the promise constructor function in
file.js, it goes unhandled andrejectis not called, which leads to this uncaught exception (my guess)I am going to try and set the retry option to false for now, so that this default retry function would never run, and hopefully this wont be thrown, will report back later on how that goes. But I do believe the default function has a bug if it cannot handle this case. As to what causes this "weird error" where the object is null to be thrown, I've not dug that deep yet.
@google-cloud/storageversion: 5.14.8Steps to reproduce
await file.save()