Expose conjure tags as endpoint parameters #480
Conversation
Tags were previously not exposed at the endpoint level. The only tags that were effective were 'server-request-context' and 'server-limit-request-size', both of which were interpreted by conjure-rust at codegen time. Add a 'tags' function to Endpoint, which exposes the set of tags. This is similar to the java undertow generator. Forgoes adding 'tags' to the client, unlike the java dialogue implementation. This is because the clients are used directly in rust, as opposed to being passed into a dialogue client generator.
Generate changelog in
|
There was a problem hiding this comment.
Pull Request Overview
This PR adds support for exposing Conjure tags as endpoint parameters in the Rust implementation. Previously, tags were only interpreted at codegen time for specific purposes like 'server-request-context' and 'server-limit-request-size'.
- Adds a
tags()method to theEndpointMetadatatrait to expose endpoint tags - Implements tag parsing in the macro system to accept tags as endpoint parameters
- Updates code generation to include tags in endpoint attribute syntax
Reviewed Changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| conjure-macros/src/endpoints.rs | Adds tag parsing logic and generates tag metadata for endpoints |
| conjure-http/src/server/mod.rs | Extends EndpointMetadata trait with tags() method and implements for wrapper types |
| conjure-codegen/src/servers.rs | Updates code generation to include tags in endpoint attribute syntax |
Comments suppressed due to low confidence (1)
conjure-codegen/src/servers.rs:174
- The variable name 'tags' shadows the function name 'tags' in the same scope, which reduces code clarity. Consider renaming the variable to 'tags_token' or 'formatted_tags'.
let tags = crate::servers::tags(endpoint.tags());
| let punctuated: Punctuated<LitStr, Token![,]> = Punctuated::parse_terminated(&content)?; | ||
|
|
||
| for lit_str in punctuated { |
There was a problem hiding this comment.
[nitpick] Consider using a more descriptive variable name than 'punctuated' to improve code readability, such as 'tag_literals' or 'comma_separated_tags'.
| let punctuated: Punctuated<LitStr, Token![,]> = Punctuated::parse_terminated(&content)?; | |
| for lit_str in punctuated { | |
| let tag_literals: Punctuated<LitStr, Token![,]> = Punctuated::parse_terminated(&content)?; | |
| for lit_str in tag_literals { |
|
Out of curiosity, what's the use case for doing this? My general preference up to now was to have the code generator parse out the tags and handle all of the special casing up front rather than deferring it to runtime. |
|
@sfackler Use case here is to expose the 'no-response-compression' tag to the witchcraft layer. I could also just add a specific case handler to the code generator for witchcraft to pick up instead of exposing tags in general, since it's evident that there haven't really been that many tags. |
|
Yeah I think the easiest thing for that is to just have conjure-codegen inject a |
|
This PR has been automatically marked as stale because it has not been touched in the last 14 days. If you'd like to keep it open, please leave a comment or add the 'long-lived' label, otherwise it'll be closed in 7 days. |
Tags were previously not exposed at the endpoint level. The only tags that were effective were 'server-request-context' and 'server-limit-request-size', both of which were interpreted by conjure-rust at codegen time.
Add a 'tags' function to Endpoint, which exposes the set of tags. This is similar to the java undertow generator.
Forgoes adding 'tags' to the client, unlike the java dialogue implementation. This is because the clients are used directly in rust, as opposed to being passed into a dialogue client generator.