fix: propagate required flag to @RequestHeader-derived headers - #1441
Conversation
|
📦 Plugin has been packaged for this PR. You can download it from the GitHub Actions workflow run by clicking on the "Artifacts" dropdown:
Each artifact is a ready-to-install plugin zip — pick the one matching your IDEA version and install it via Settings → Plugins → ⚙ → Install Plugin from Disk. No extraction needed. |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #1441 +/- ##
=============================================
+ Coverage 66.805% 66.834% +0.028%
=============================================
Files 468 468
Lines 27146 27169 +23
Branches 6520 6522 +2
=============================================
+ Hits 18135 18158 +23
Misses 6544 6544
Partials 2467 2467
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 1 file with indirect coverage changes Continue to review full report in Codecov by Harness.
🚀 New features to boost your workflow:
|
Header parameters declared with @RequestHeader are exported through a dedicated extractParamHeaders branch that built ApiHeader without consulting the param.required rule, so headers always carried required=false and YApi req_headers[].required was always 0. - resolve param.required for header-bound parameters in the Spring MVC, JAX-RS and custom exporters - add RuleEngine.evaluateOrNull and DocMetadataResolver.resolveParamRequired so a framework default can be applied when no rule is configured: @RequestHeader is required unless required=false is declared - add regression tests covering the Spring default, the custom-rule override and rule precedence, plus a YApi formatter contract test
d0f72ec to
a1a127f
Compare
|
📦 Plugin has been packaged for this PR. You can download it from the GitHub Actions workflow run by clicking on the "Artifacts" dropdown:
Each artifact is a ready-to-install plugin zip — pick the one matching your IDEA version and install it via Settings → Plugins → ⚙ → Install Plugin from Disk. No extraction needed. |
|
Confirmed working. I installed the artifact build (
Thanks for the quick fix! Looking forward to the next release. |
Summary
Fixes #1440: header parameters declared with
@RequestHeaderwere exported through adedicated
extractParamHeadersbranch that builtApiHeaderwithout consulting theparam.requiredrule. As a result headers always carriedrequired = falseand YApireq_headers[].requiredwas always0, even when the rule resolved totrue.Changes
SpringMvcClassExporter):param.requirednow wins when configured;when no rule is set, the Spring default is applied in code —
@RequestHeaderisrequired unless
required = falseis declared explicitly.JaxRsClassExporter) and custom framework (CustomClassExporter):param.requiredis now honoured for header-bound parameters (previously alwaysemitted
required = false).RuleEngine.evaluateOrNullandDocMetadataResolver.resolveParamRequiredso a framework-specific default can beapplied only when no rule is configured.
req_headers[].required) and OpenAPI (header.required) consumers now see thecorrect flag.
Tests
SpringMvcRequestHeaderRequiredTest— covers the Spring default (no rules), theexact custom rule from the report, and rule-overrides-default precedence.
JaxRsHeaderRequiredTest— covers rule-driven required propagation for@HeaderParam.YapiFormatterTest— added a contract test for thereq_headers[].requiredmapping.All new tests pass and the
com.itangcent.easyapi.framework.*package is green. Thefull suite could not be completed on this machine because the test executor JVM runs
out of native memory (pre-existing environment limitation, unrelated to this change).
Notes
param.requiredrule,@RequestParam(query params) keeps its currentbehaviour (optional). Aligning
@RequestParamwith the Spring default would be aseparate, broader change.
param.namerule still falls back to theJava parameter name rather than the
@RequestHeadervalue — pre-existing behaviour,out of scope here.