starred/fake-gcs-server

Fork 0

mirror of https://github.com/fsouza/fake-gcs-server.git synced 2026-04-25 13:45:52 +03:00

[GH-ISSUE #1468] Object metadata does not update if a key is removed #202

New issue

Open

opened 2026-03-03 12:09:06 +03:00 by kerem · 4 comments

kerem commented

2026-03-03 12:09:06 +03:00

Owner

Originally created by @KeithKeithDev on GitHub (Jan 30, 2024).
Original GitHub issue: https://github.com/fsouza/fake-gcs-server/issues/1468

Using version: 1.47.6

I create an object with the initial custom metadata:

{foo=bar, baz=qux}

When trying to update the object's metadata with the following map (e.g. the 'foo' entry is now removed)
{baz=qux}

using the following code (as per the google gcs documentation here):

val updated = blob.toBuilder.setMetadata(metadata.asJava).build().update()
println(s"Updated metadata ${updated.getMetadata.asScala}")

The following is logged and we can see that the foo entry is still there.
Updated metadata Map(baz -> qux, foo -> bar)

However, if I update the object by changing the mapping of a single entry, so I update with:
{baz=blah}

Then I can see that the object's metadata is now updated to have just the 1 key and the foo mapping is gone, as expected:
Updated metadata Map(baz -> blah)

Is this a bug?

Originally created by @KeithKeithDev on GitHub (Jan 30, 2024). Original GitHub issue: https://github.com/fsouza/fake-gcs-server/issues/1468 Using version: 1.47.6 I create an object with the initial custom metadata: `{foo=bar, baz=qux}` When trying to update the object's metadata with the following map (e.g. the 'foo' entry is now removed) `{baz=qux}` using the following code (as per the google gcs documentation [here](https://cloud.google.com/storage/docs/viewing-editing-metadata#edit)): ``` val updated = blob.toBuilder.setMetadata(metadata.asJava).build().update() println(s"Updated metadata ${updated.getMetadata.asScala}") ``` The following is logged and we can see that the `foo` entry is still there. `Updated metadata Map(baz -> qux, foo -> bar)` However, if I update the object by _changing the mapping_ of a single entry, so I update with: `{baz=blah}` Then I can see that the object's metadata is now updated to have just the 1 key and the `foo` mapping is gone, as expected: `Updated metadata Map(baz -> blah)` Is this a bug?

kerem added the

bug

label

2026-03-03 12:09:06 +03:00

kerem commented

2026-03-03 12:09:07 +03:00

Author

Owner

@fsouza commented on GitHub (Feb 8, 2024):

@KeithKeithDev thanks for reporting! This is definitely unexpected.

@fsouza commented on GitHub (Feb 8, 2024): @KeithKeithDev thanks for reporting! This is definitely unexpected.

kerem commented

2026-03-03 12:09:07 +03:00

Author

Owner

@KeithKeithDev commented on GitHub (Mar 4, 2024):

@fsouza actually, I may have been making the wrong API call. To delete a key, you need to set a mapping to null for that key as per https://cloud.google.com/storage/docs/json_api#patch. So in reality, I should have called setMetadata with foo -> null.

However, I see another potential issue.

I create an object with initial metadata mapping "foo" -> "bar"
I run the curl command to see the object in fake-gcs-server: curl http://localhost:55007/storage/v1/b/my-bucket/o. I can see "metadata":{"foo":"bar"}
In my code, I call val updated = blob.toBuilder.setMetadata(metadata.asJava).build().update() with a new metadata mapping of "baz" -> "qux".
When I run the same curl command against fake-gcs-server again, to see the object's metadata, curl http://localhost:55007/storage/v1/b/my-bucket/o. I can see "metadata":{"baz":"qux"}

It looks like the original metadata is wiped. https://cloud.google.com/storage/docs/json_api#patch. Can you reproduce this and confirm if it's an issue?

@KeithKeithDev commented on GitHub (Mar 4, 2024): @fsouza actually, I may have been making the wrong API call. To delete a key, you need to set a mapping to null for that key as per https://cloud.google.com/storage/docs/json_api#patch. So in reality, I should have called setMetadata with `foo -> null`. However, I see another potential issue. 1. I create an object with initial metadata mapping "foo" -> "bar" 2. I run the curl command to see the object in fake-gcs-server: `curl http://localhost:55007/storage/v1/b/my-bucket/o`. I can see `"metadata":{"foo":"bar"}` 3. In my code, I call `val updated = blob.toBuilder.setMetadata(metadata.asJava).build().update()` with a new metadata mapping of "baz" -> "qux". 4. When I run the same curl command against fake-gcs-server again, to see the object's metadata, `curl http://localhost:55007/storage/v1/b/my-bucket/o`. I can see `"metadata":{"baz":"qux"}` It looks like the original metadata is wiped. https://cloud.google.com/storage/docs/json_api#patch. Can you reproduce this and confirm if it's an issue?

kerem commented

2026-03-03 12:09:07 +03:00

Author

Owner

@KeithKeithDev commented on GitHub (Mar 4, 2024):

@fsouza - also, another potential issue.

When deleting a metadata item, it appears that the keys still exist, although the mapped value is "null". For example, if I call:

val toDelete: Map[String, String] = Map("foo" -> null)
val updated = blob.toBuilder.setMetadata(toDelete.asJava).build().update()

If I then call updated.getMetadata, I see: Map(foo -> ). If I do the same test against GCS, I can see it deletes the 'foo' metadata item.

@KeithKeithDev commented on GitHub (Mar 4, 2024): @fsouza - also, another potential issue. When deleting a metadata item, it appears that the keys still exist, although the mapped value is "null". For example, if I call: ``` val toDelete: Map[String, String] = Map("foo" -> null) val updated = blob.toBuilder.setMetadata(toDelete.asJava).build().update() ``` If I then call `updated.getMetadata`, I see: `Map(foo -> )`. If I do the same test against GCS, I can see it deletes the 'foo' metadata item.

kerem commented

2026-03-03 12:09:07 +03:00

Author

Owner

@noamshvacher commented on GitHub (Jun 17, 2024):

Hi, any updates on that? I'm experiencing the same issue here

@noamshvacher commented on GitHub (Jun 17, 2024): Hi, any updates on that? I'm experiencing the same issue here

kerem referenced this issue

2026-03-15 17:57:00 +03:00

[GH-ISSUE #202] Dependabot can't parse your go.mod #2184