Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 17 additions & 3 deletions models/backbeatRoutes/putMetadata.smithy
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,8 @@ namespace cloudserver.backbeatRoutes
@http(method: "PUT", uri: "/_/backbeat/metadata/{Bucket}/{Key+}")
operation PutMetadata {
input: PutMetadataInput,
output: PutMetadataOutput
output: PutMetadataOutput,
errors: [StaleMicroVersionIdException]
}

structure PutMetadataInput {
Expand Down Expand Up @@ -33,12 +34,25 @@ structure PutMetadataInput {

@httpHeader("X-Scal-Request-Uids")
RequestUids: String,


@httpHeader("x-scal-micro-version-id")
MicroVersionId: String,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: to make the semantic explicit, field could be name something like IfMicroVersionIdOlderThan (i.e. semantics is part of the API)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leaving for now, what do other ppl think about the naming ?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@scality/raving-robots WDYT?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

x-scal-micro-version-id is simpler and easier to understand.


@httpPayload
Body: Blob
}

structure PutMetadataOutput {
/// Version ID of the stored metadata
versionId: String
versionId: String,

@httpHeader("x-scal-replication-loop")
ReplicationLoop: Boolean
}

@error("client")

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we add a test for this changes the generated client contract, but nothing checks that MicroVersionId / versionId are serialized as headers, nor that the new 409 errors are deserialized with their headers

@httpError(409)
structure StaleMicroVersionIdException {
@required
message: String
}
18 changes: 16 additions & 2 deletions models/backbeatRoutes/putdata.smithy
Comment thread
maeldonn marked this conversation as resolved.

@SylvainSenechal SylvainSenechal May 29, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First I added some tests in this codebase, but they were too functional and not really oriented toward just testing the client itself. + we already have test testing the client itself for putData/putMetadata

So I added the tests in Cloudserver : They are functional tests using CloudserverClient with the micro version id, testing 409 error, actual api behavior etc. I think they are better in cloudserver than in here

Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,8 @@ use aws.auth#unsignedPayload
@unsignedPayload
operation PutData {
input: PutDataInput,
output: PutDataOutput
output: PutDataOutput,
errors: [VersionIdCollisionException]
}

structure PutDataInput {
Expand All @@ -31,6 +32,9 @@ structure PutDataInput {
@httpHeader("X-Scal-Request-Uids")
RequestUids: String,

@httpHeader("x-scal-source-version-id")

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why "source" ? you usual header is x-scal-version-id I think, should stick to it ?

@SylvainSenechal SylvainSenechal Jun 8, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In a code that's already not super easy to read, I think its easy to mix up ids, and being able to write this on cloudserver just make thing very clear 🤔

const incomingVersionIdEncoded = request.headers['x-scal-source-version-id'];

edit: Yeah actually in cloudserver, we already have similar pattern in routebackbeat (x-scal-source-version-id, x-scal-source-bucket), so I prefer to keep it like this

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should be marked as "optional" : if not set, we should keep previous/existing behavior (no conflict detection etc)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be confirmed, but I think it's optional by default.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thats right, there is an @required field
that will produce this for example.
Else the field is optional
Image

SourceVersionId: String,

@httpPayload
@default("")
Body: StreamingBlob
Expand All @@ -45,7 +49,17 @@ structure PutDataOutput {

@httpHeader("x-amz-server-side-encryption-customer-algorithm")
SSECustomerAlgorithm: String,

@httpHeader("x-amz-server-side-encryption-aws-kms-key-id")
SSEKMSKeyId: String
}

@error("client")
@httpError(409)
structure VersionIdCollisionException {
@required
message: String,

@httpHeader("x-scal-micro-version-id")
MicroVersionId: String
}
2 changes: 1 addition & 1 deletion package.json
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"name": "@scality/cloudserverclient",
"version": "1.0.8",
"version": "1.0.9",
"engines": {
"node": ">=20"
},
Expand Down
Loading