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

[5/n] [dropshot] add support for per-endpoint size limits #1171

Conversation

sunshowers
Copy link
Contributor

@sunshowers sunshowers commented Nov 12, 2024

For some endpoints like uploading update and support bundles, we would like to
have a larger request limit. Add support for that.

This is the other half of RFD 353, after #617. (A previous attempt was #618,
which I've abandoned.)

The PR consists of:

  • The implementation.
  • A small tweak to the API generation code for better span attribution.
  • Tests.

Depends on:

Created using spr 1.3.6-beta.1
Created using spr 1.3.6-beta.1

[skip ci]
@sunshowers sunshowers changed the title [2/2] [dropshot] add support for per-endpoint size limits [2/n] [dropshot] add support for per-endpoint size limits Nov 12, 2024
@sunshowers sunshowers changed the title [2/n] [dropshot] add support for per-endpoint size limits [3/n] [dropshot] add support for per-endpoint size limits Nov 12, 2024
Created using spr 1.3.6-beta.1
Created using spr 1.3.6-beta.1

[skip ci]
@sunshowers
Copy link
Contributor Author

sunshowers commented Nov 12, 2024

I'm going to try splitting up this PR a bit. Done, this PR is almost all additions.

Created using spr 1.3.6-beta.1
Created using spr 1.3.6-beta.1

[skip ci]
@sunshowers sunshowers changed the title [3/n] [dropshot] add support for per-endpoint size limits [5/n] [dropshot] add support for per-endpoint size limits Nov 12, 2024
Created using spr 1.3.6-beta.1
Created using spr 1.3.6-beta.1

[skip ci]
Created using spr 1.3.6-beta.1
@sunshowers
Copy link
Contributor Author

I've rebased the stack on to main, resolving conflicts with #1115.

Copy link
Collaborator

@ahl ahl left a comment

Choose a reason for hiding this comment

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

I assume this would be ... fine?

#[endpoint {
    request_body_max_bytes = "100000".try_into().unwrap(),
    ....
}

Yeah?

This all looks good

Comment on lines 44 to 45
/// // Optional maximum request body size in bytes
/// request_body_max_bytes = 1 * 1024 * 1024,
Copy link
Collaborator

Choose a reason for hiding this comment

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

I know tags indicates that it's optional, but all these are optional. I would suggest:

/// #[endpoint {
///     // Required fields
///     method = { DELETE | HEAD | GET | OPTIONS | PATCH | POST | PUT },
///     path = "/path/name/with/{named}/{variables}",
///
///     // Optional fields
///     // Tags to be included in the OpenAPI document
///     tags = [ "all", "your", "OpenAPI", "tags" ],
///     // Specifies the media type used to encode the request body
///     content_type = { "application/json" | "application/x-www-form-urlencoded" | "multipart/form-data" }
///     // A value of `true` marks the operation as deprecated
///     deprecated = { true | false },
///     // A value of `true` causes the operation to be omitted from the API description
///     unpublished = { true | false },
///     // Maximum request body size in bytes; may be any rust expression including a constant.
///     request_body_max_bytes = 1 * 1024 * 1024,

Small suggestion for clarity of the value, but I'm not in love with what I wrote...

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'll try and make this clearer, good catch.

@sunshowers
Copy link
Contributor Author

I assume this would be ... fine?

Yeah, any expression that evaluates to a usize would work (doesn't need to be a const expression specifically).

Created using spr 1.3.6-beta.1

[skip ci]
Created using spr 1.3.6-beta.1
/// unpublished = { true | false },
/// // Optional maximum request body size in bytes
/// // Maximum request body size in bytes (default: server config default_request_body_max_bytes)
Copy link
Collaborator

Choose a reason for hiding this comment

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

this is good, but I think it would be nice to let people know that a CONSTANT would be fine here (the fact that any expression works is fine, but I think the interesting thing is that a constant works).

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 was trying to keep the comment short to be honest. I think the best thing to do here would be to use Markdown for all the configuration parameters, similar to the tag configuration section below.

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've expanded the docs and added a clearer hint about being able to use constants.

sunshowers added a commit that referenced this pull request Nov 16, 2024
…#1173)

In upcoming work (#1171), we're going to add optional per-endpoint size limits.
To make it clear that per-endpoint limits always override whatever's specified
in the configuration, rename this field.

(Without the rename, it can be confusing to determine what happens if the
per-endpoint limit is smaller than the configuration limit.)

Also add a deserialize-time check to fail if `request_body_max_bytes` is
specified, guiding users to the new name.
sunshowers added a commit that referenced this pull request Nov 16, 2024
This is part of `RequestContext`, and returns metadata that's stored on the
endpoint.

In upcoming work (#1171) we're going to add per-endpoint size limits to this
struct.
@sunshowers sunshowers changed the base branch from sunshowers/spr/main.22-dropshot-add-support-for-per-endpoint-size-limits to main November 16, 2024 20:56
Created using spr 1.3.6-beta.1
Copy link
Collaborator

@davepacheco davepacheco left a comment

Choose a reason for hiding this comment

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

Nice! Nothing major here, just a few doc requests and a suggestion.

CHANGELOG.adoc Show resolved Hide resolved
dropshot/src/handler.rs Outdated Show resolved Hide resolved
@@ -218,6 +224,9 @@ pub struct RequestEndpointMetadata {

/// The expected request body MIME type.
pub body_content_type: ApiEndpointBodyContentType,

/// The maximum number of bytes allowed in the request body, if overridden.
pub request_body_max_bytes: Option<usize>,
Copy link
Collaborator

Choose a reason for hiding this comment

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

What do you think of calling this request_body_max_bytes_override? (I'm honestly not sure. Sometimes I find that suffix clarifies that what might be here is an override of some other value that comes from some place else. Otherwise, you might think that if this were None that there was no limit.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm, not sure -- personally I feel like if you're using this you're likely also aware of the default in the config, maybe? I generally lean towards shorter names over spelling things out completely, especially when there's a clear chain of implication.

@@ -707,7 +707,7 @@
//!
Copy link
Collaborator

Choose a reason for hiding this comment

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

This comment belongs at L309, but, you know, thanks GitHub.

I think you want to add this to the synopsis at L309 and also add a note about it in that section (#[endpoint { ... }] attribute parameters) around L322).

Copy link
Contributor Author

@sunshowers sunshowers Nov 20, 2024

Choose a reason for hiding this comment

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

Hmm, the synopsis doesn't cover all the arguments today so it would be a bigger change. I can make this change but it would be a substantial one that I would do separately.

(This is where I feel like not having everything in the lib.rs documentation, but instead having an external documentation site, might be useful.)

Copy link
Contributor Author

@sunshowers sunshowers Nov 20, 2024

Choose a reason for hiding this comment

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

Oh, so I just realized that versions is specified in dropshot/src/lib.rs but not in the dropshot_endpoint::endpoint documentation. There are also several parameters described in endpoint but not in dropshot/src/lib.rs.

Yikes -- I think the list of arguments should only be specified in one spot!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

#1181 does that. I'd like to not block on it if that's ok, I think that's a bigger fix that should be done in a followup.

Created using spr 1.3.6-beta.1
Created using spr 1.3.6-beta.1
@sunshowers sunshowers enabled auto-merge (squash) November 21, 2024 03:20
@sunshowers sunshowers merged commit d5874eb into main Nov 21, 2024
10 checks passed
@sunshowers sunshowers deleted the sunshowers/spr/22-dropshot-add-support-for-per-endpoint-size-limits branch November 21, 2024 03:27
sunshowers added a commit that referenced this pull request Nov 26, 2024
In the review for #1171 I realized that we were specifying the endpoint
attribute params in two places, neither of which had a complete list. Put it
all in one place: on documentation for the proc macro.

Also move the documentation to `dropshot/src/lib.rs` to allow doctests to work.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants