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

Support the STORAGE_EMULATOR_HOST environment variable for StorageClient #11522

Closed
EricStG opened this issue Jan 11, 2024 · 8 comments
Closed
Assignees
Labels
type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.

Comments

@EricStG
Copy link

EricStG commented Jan 11, 2024

Is your feature request related to a problem? Please describe.
We're using the firebase emulator, and we want to be able to configure the StorageClient via environment variables

Describe the solution you'd like
We'd like to be able to configure the StorageClient's host via the STORAGE_EMULATOR_HOST environment variable

Describe alternatives you've considered
We are currently setting the address via code, as described here.

Additional context
This is already supported by the GO and Node clients

@jskeet
Copy link
Collaborator

jskeet commented Jan 11, 2024

Will have a look at this. One thing that the .NET libraries are consistent about is not just using an environment variable. We'd do this in the same way - see https://cloud.google.com/dotnet/docs/reference/help/emulators for examples.

(I wasn't aware that the Firebase emulator implemented a full Storage service... Will need to test it thoroughly.)

@jskeet jskeet self-assigned this Jan 11, 2024
@jskeet jskeet added the type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design. label Jan 11, 2024
@jskeet
Copy link
Collaborator

jskeet commented Jan 15, 2024

Hmmm... I've just had made a first attempt at this, and the emulator just rejects all requests. I need to look in more detail as to what it will accept.

@jskeet
Copy link
Collaborator

jskeet commented Jan 15, 2024

Ah - my mistake, I'd used the emulator UI port instead of the API port. Doh. Looks like it's working now - with the limitations around no bucket operations, etc. Will see if I can get it more production-ready and create a PR.

@EricStG
Copy link
Author

EricStG commented Jan 15, 2024

We have it working here without any changes, at least for basic upload/download
Except for a workaround on UpdateObjectAsync, which fails (we haven't dug too much into it for our needs though)

@jskeet
Copy link
Collaborator

jskeet commented Jan 15, 2024

Will look into UpdateObjectAsync as part of the work - thanks for calling that out.

@EricStG
Copy link
Author

EricStG commented Jan 15, 2024

We were having errors trying to update both CacheControl and Metadata with UpdateObjectAsync.
The error was:

The service storage has thrown an exception.
HttpStatusCode is NotImplemented.
No JSON error details were specified.
Raw error details are: Not Implemented

Could be a limitation on the emulator, but it would not be documented.

@jskeet
Copy link
Collaborator

jskeet commented Jan 16, 2024

Yes, I suspect it's an emulator limitation - as you say, object update claims to be supported, but I get the same results as you, even changing a different field (customDateTime). I can patch a change to metadata, but not a change to customDateTime. I don't know how the Firebase Emulator versioning keeps up with the Storage API versioning. I'll ask internally about the object update part not working, but obviously that's somewhat separate to the client library support itself.

@jskeet
Copy link
Collaborator

jskeet commented Jan 20, 2024

This is implemented in #11535, which will be in the next release.

@jskeet jskeet closed this as completed Jan 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.
Projects
None yet
Development

No branches or pull requests

2 participants