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

Correctly prefix storage emulator routes #3786

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

jcmorrow
Copy link

Description

Hello! This is my attempt at a bug-fix, I don't think there are related issues, but there might be. I sunk like six hours into figuring this out yesterday, and of course the fix turned out to be a change of ~10 characters. Let me give some context as to how I got here:

  • I am working on an application that hits the storage API at start-up time, and I wanted to spin up local emulators so that new devs wouldn't need to have a fully-set-up cloud project just to run a local server.
  • I got the local emulator running, interacted with it via the WebUI, confirmed that it was working, but when I tried to list the buckets, or list objects in a particular bucket from my Go code, it failed.
  • With a bit of digging, I realized that it was failing because the server was returning 501 not implemented.
  • I decided to take a different tack, since in the docs of the client library it mentions that buckets are implicitly created upon writing an object in them. I decided to try and write an object to a bucket, and that created the bucket just fine, I could see it in the webUI and everything. You can see me live debugging this a bit on the Slack
  • Anyways, long story short, I dug into the code this morning and saw that some of the routes for the storage emulator are prefixed with /storage/v1 and some are not.
  • The Go client library explicitly sets that prefix as the root path: https://github.com/googleapis/google-cloud-go/blob/0e7ccf1cc95c84838cc3de722ff4cc2e5098f579/storage/storage.go#L143. I don't know if the other client libraries do this, but it seems reasonable, since all of the documentation includes that prefix.
  • I don't see any tests that cover how routes link up to actions, so I'm not adding anything here, but I've confirmed that this works with the Go client library as expected.

Scenarios Tested

I have only worked with the Go client library, and I have not
double-checked that all client libraries force this prefix, but it seems
likely. Either way, I've left the origin, unprefixed routes in place,
but added prefixed routes.

Here's a little about how this manifested for me:

- I am working on an application that hits the storage API at start-up
  time, and I wanted to spin up local emulators so that new devs
  wouldn't need to have a fully-set-up cloud project just to run a loca
  server.
- I got the local emulator running, interacted with it via the WebUI,
  confirmed that it was working, but when I tried to list the buckets,
  or list objects in a particular bucket from my Go code, it failed.
- With a bit of digging, I realized that it was failing because the
  server was returning 501 not implemented.
- I decided to take a different tack, since in the docs of the client
  library it mentions that buckets are implicitly created upon writing
  object, I decided to try and write an object instead of creating a
  bucket, and that worked just fine!
- Anyways, long story short, I dug into the code here and saw that
  *some* of the routes for the storage emulator are prefixed with
  `/storage/v1` and some are not.
- The Go client library explicitly sets that prefix as the root path: https://github.com/googleapis/google-cloud-go/blob/0e7ccf1cc95c84838cc3de722ff4cc2e5098f579/storage/storage.go#L143
- I don't see any tests that test specifically that a particular route
  links to a particular action, so I'm not adding anything here, but
  I've confirmed that this works with the Go client library as expected.
@google-cla
Copy link

google-cla bot commented Sep 25, 2021

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.


What to do if you already signed the CLA

Individual signers
Corporate signers

ℹ️ Googlers: Go here for more info.

@google-cla google-cla bot added the cla: no label Sep 25, 2021
@jcmorrow
Copy link
Author

@googlebot I signed it!

@google-cla google-cla bot added cla: yes Manual indication that this has passed CLA. and removed cla: no labels Sep 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla: yes Manual indication that this has passed CLA.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant