Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fallback to non-resumable not working when $HOME is not writable #181

Closed
ofrobots opened this issue Apr 26, 2018 · 12 comments
Closed

Fallback to non-resumable not working when $HOME is not writable #181

ofrobots opened this issue Apr 26, 2018 · 12 comments
Assignees
Labels
api: storage Issues related to the googleapis/nodejs-storage API. 🚨 This issue needs some love. triage me I really want to be triaged. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns.

Comments

@ofrobots
Copy link

ofrobots commented Apr 26, 2018

The docs claim:

https://cloud.google.com/nodejs/docs/reference/storage/1.6.x/File#createWriteStream

Resumable uploads require write access to the $HOME directory. Through config-store, some metadata is stored. By default, if the directory is not writable, we will fall back to a simple upload. However, if you explicitly request a resumable upload, and we cannot write to the config directory, we will return a ResumableUploadError.

However, I am getting the following error in an environment where $HOME is not writable.

A  Error: EROFS: read-only file system, mkdir '/home/.config' 
A      at Object.fs.mkdirSync (fs.js:885:18) 
A      at make (/srv/node_modules/make-dir/index.js:59:12) 
A      at make (/srv/node_modules/make-dir/index.js:66:5) 
A      at Function.module.exports.sync (/srv/node_modules/make-dir/index.js:82:9) 
A      at Configstore.get all [as all] (/srv/node_modules/configstore/index.js:34:13) 
A      at new Configstore (/srv/node_modules/configstore/index.js:25:47) 
A      at new Upload (/srv/node_modules/gcs-resumable-upload/index.js:64:22) 
A      at Upload (/srv/node_modules/gcs-resumable-upload/index.js:28:41) 
A      at File.startResumableUpload_ (/srv/node_modules/@google-cloud/storage/src/file.js:2278:22) 
A      at Pumpify.<anonymous> (/srv/node_modules/@google-cloud/storage/src/file.js:959:12) 

And the upload fails. The fallback to non-resumable uploads is not working as claimed in the docs.

@stephenplusplus
Copy link
Contributor

What version of GCS & code to reproduce?

@ofrobots
Copy link
Author

$ grep "google-cloud/storage" package-lock.json
    "@google-cloud/storage": {
      "resolved": "https://registry.npmjs.org/@google-cloud/storage/-/storage-1.6.0.tgz",

Code:

import * as express from 'express';
const Storage = require('@google-cloud/storage');

const config = {
  projectId: $INSERT_YOUR_PROJECT_ID,
  bucketName: $INSERT_YOUR_BUCKET_NAME
};
const storage = new Storage({projectId: config.projectId});

const BUCKET_URL = `https://storage.googleapis.com/${config.bucketName}`;

const app = express();

app.post('/upload', async (req, res) => {
  const id = 'a-random-uuid';
  const file = storage.bucket(config.bucketName).file(id);
  req.pipe(file.createWriteStream({gzip: true, public: true}))
      .on('error',
          (err: Error) => {
            res.status(500).send({err});
          })
      .on('finish', () => {
        const rawUrl = `${BUCKET_URL}/${id}`;
        res.status(200).send({rawUrl});
      });
});
app.listen(8080, (err: Error) => {
  if (err) {
    throw err;
  }
  console.log('Server listening on port 8080');
});

Hit it:

$ curl -X POST http://localhost:8080/upload -H 'Content-Type:application/json' -d @$HOME/$SOMEFILE

@stephenplusplus stephenplusplus added type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns. priority: p2 Moderately-important priority. Fix may not be included in next release. labels Apr 26, 2018
@ofrobots
Copy link
Author

The expected work-around of passing resumable: false option to File#createWriteStream doesn't seem to help.

This is a blocker for a product launch, and no work-around is known at this point. Can the priority be increased?

@stephenplusplus
Copy link
Contributor

Looks like we haven't released the behavior you're expecting: #165

@frankyn @jonparrott @alexander-fenster -- advice on how to proceed, please! Would you like a new release without KMS so that this product launch is unblocked, or wait for KMS?

@theacodes
Copy link

Let's wait for KMS unless this is a P0 bug.

@frankyn
Copy link
Member

frankyn commented Apr 27, 2018

Wait on merging KMS, I don't have a recommendation on cutting release for this bug.

@ofrobots
Copy link
Author

ofrobots commented Apr 27, 2018 via email

@ofrobots
Copy link
Author

I am personally blocked on this bug as well. What's the ETA on KMS getting into a release?

@theacodes
Copy link

@stephenplusplus since we haven't merged KMS stuff, can we go ahead and cut a release?

@ofrobots
Copy link
Author

ofrobots commented May 4, 2018

gentle ping

@stephenplusplus
Copy link
Contributor

Blocked on #190

@stephenplusplus
Copy link
Contributor

1.7.0 released with this feature :)

@ghost ghost removed the priority: p2 Moderately-important priority. Fix may not be included in next release. label May 22, 2018
@google-cloud-label-sync google-cloud-label-sync bot added the api: storage Issues related to the googleapis/nodejs-storage API. label Jan 31, 2020
@yoshi-automation yoshi-automation added 🚨 This issue needs some love. triage me I really want to be triaged. labels Apr 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: storage Issues related to the googleapis/nodejs-storage API. 🚨 This issue needs some love. triage me I really want to be triaged. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
Projects
None yet
Development

No branches or pull requests

5 participants