mirror of
https://github.com/fsouza/fake-gcs-server.git
synced 2026-04-26 06:05:54 +03:00
[GH-ISSUE #1624] storage.create function deprecated - storage.createFrom() hangs #208
Labels
No labels
bug
compatibility-issue
docker
documentation
enhancement
help wanted
needs information
pull-request
question
stale
unfortunate
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/fake-gcs-server#208
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @oliverjstack on GitHub (May 30, 2024).
Original GitHub issue: https://github.com/fsouza/fake-gcs-server/issues/1624
Overview
Using the com.google.cloud:spring-cloud-gcp-storage:5.0.4 library the storage.create() function has now been listed as deprecated to upload files to GCS bucket.
They now have a createFrom() function that achieves the same outcome however seems when it interacts with the GCS server (fake-gcs-server) it fails.
Notes
Summary
I appreciate that you guys are seemingly the only way to create a fake gcs server allowing integration testing to proceed. I think its crazy that Google has no simple image that can emulate their own server functionality.
Let me know if I need to add anything or what you guys require from me. For now, Ill just be using the GCP SDK local helper client to emulate the storage but would love to use your solution if this problem is resolved.
@fsouza commented on GitHub (May 30, 2024):
Can you share a stack trace of the failure and how to reproduce it?
@marcuslinke commented on GitHub (Dec 20, 2024):
@fsouza There is no stacktrace. It just hangs indefinitely.
@fsouza commented on GitHub (Jan 3, 2025):
@marcuslinke can you share a complete reproducer? I suspect the new method is expecting something different but I'm not sure what.
@sigpwned commented on GitHub (May 9, 2025):
I ran across this issue from the Java GCS client. I have no idea what languages other folks are using.
Here is a (reasonably) simple Java application that shows off the issue:
The first
assertThat()against blob1 passes. TheassertTimeoutPreemptively()never returns.EDIT: Actually, if I set the timeout high enough (30 seconds does it, but fewer might, too), I get this error:
I know from previous experience that anything using a
WriteableByteChannelfails, too. This example uses aWriteableByteChannelunder the covers in the client. That doesn't meanWriteableByteChannelis the root cause, but it's an interesting note.The
ConnectExceptionis odd. We know that the storage client can talk to the emulator, since it does earlier in the test. But now it can't see the emulator? I wrapped the timeout code in a try/finally, put a breakpoint in the finally, and then was able to curl the emulator while the program was paused, so I know the emulator didn't just crash.This makes me lean towards a client error. But this is the only mention I've found of the bug, so I figured I'd put my learnings here in the hopes that it helps others in the future!
@mihohren commented on GitHub (Jun 26, 2025):
Can confirm issue is still present in
latestas of today@lberrymage commented on GitHub (Dec 18, 2025):
I don't think this is a bug with fake-gcs-server, but a configuration issue when running fake-gcs-server in a container as described in #637.
createFrom()initiates a resumable upload with a POST to fake-gcs-server and then makes subsequent requests to the endpoint returned in theLocationheader returned in the first request. If you run fake-gcs-server in a Docker container with a port mapping different than the default (which testcontainers in particular encourages), then only the first request will succeed — subsequent requests will hang because fake-gcs-server's default value for theLocationheader uses the listening port, not the port that is exposed to the Docker host, causing those requests to be made to an unreachable endpoint. My guess is that's where theConnectionExceptionis coming from.I ran into what appears to be this same issue today and confirmed the problem by statically mapping port 4443 to the same port on my Docker host for my testcontainers container, which successfully worked around the issue.
I believe passing a proper value for
-external-urlwould work as well, although obviously that's more difficult since you don't know the dynamically mapped port of the container until it's started.