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

Clarify that the syntax of instance_name is decided by the server #245

Merged
merged 2 commits into from
Apr 11, 2023
Merged
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
9 changes: 5 additions & 4 deletions build/bazel/remote/execution/v2/remote_execution.proto
Original file line number Diff line number Diff line change
Expand Up @@ -212,10 +212,11 @@ service ActionCache {
// `{instance_name}/uploads/{uuid}/blobs/{digest_function/}{hash}/{size}{/optional_metadata}`
//
// Where:
// * `instance_name` is an identifier, possibly containing multiple path
// segments, used to distinguish between the various instances on the server,
// in a manner defined by the server. If it is the empty path, the leading
// slash is omitted, so that the `resource_name` becomes
// * `instance_name` is an identifier used to distinguish between the various
Copy link
Collaborator

Choose a reason for hiding this comment

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

Though I'm fine with with improving/relaxing the description slightly, could we please make sure the emphasis remains on the fact that it's path like?

Buildbarn, for example, does not allow you to provide an instance name beginning/ending with slashes, and containing multiple successive slashes. The reason being that it would otherwise be pretty hard to embed them in local file system paths and URLs.

(Maybe we should use this occasion to add "." and ".." to the list of forbidden path segments.)

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure that we should forbid anything here, without asking around if it would break any existing implementations first. At the moment it's entirely server-implementation-defined, which seems to be working OK?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree that we should probably look into restricting what's allowed (e.g., no // or / at the end or . or ..), but I agree with @mostynb that that'll need coordination with existing implementations and is out of scope for this PR.

My intent here is to make it more clear that it's up to the server to decide what is and is not allowed for that specific implementation. If a server wants [a-z0-9]+ here, it's free to reject anything that doesn't follow that syntax. If a server wants projects/123/instance/foo, so be it. Just like it is today.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm not convinced that this should be restricted to path-like strings (although I don't have a concrete idea of why someone would want to use something non-path-like). In any case, if we're going to restrict it further, I agree with @mostynb that we need to broadcast that change and check that we're not breaking anyone.

// instances on the server. Syntax and semantics of this field are defined
// by the server; Clients must not make any assumptions about it (e.g.,
// whether it spans multiple path segments or not). If it is the empty path,
// the leading slash is omitted, so that the `resource_name` becomes
// `uploads/{uuid}/blobs/{digest_function/}{hash}/{size}{/optional_metadata}`.
// To simplify parsing, a path segment cannot equal any of the following
// keywords: `blobs`, `uploads`, `actions`, `actionResults`, `operations`,
Expand Down