Tags: apple/swift-openapi-runtime
Tags
[CI] Enable Linux nightly main on PRs (#137) ### Motivation PR CI was missing testing with nighly Linux toolchains from main. ### Modifications Enable nightly toolchain CI as well. ### Result More test coverage on PRs. ### Test Plan See this PR's CI if this works or if we need more changes.
Refactor URIDecoder/URIParser to improve handling of the deepObject s… …tyle (#127) ### Motivation As part of apple/swift-openapi-generator#259, adding deepObject parameter style support, the initial PR wasn't complete. And once we dug more into it, turns out the original implementation of the URIDecoder/URIParser didn't really lend themselves well for handling deepObject, and the recent additions of supporting arrays within dictionaries (#120) further confused the implementation. ### Modifications Refactored URIParser/URIDecoder with a clearer understanding of the current requirements. It's now much easier to follow and embraces the fact that each of the 7 variants of URI coding we support (form exploded, form unexploded, simple exploded, simple unexploded, form data exploded, form data unexploded, and now deepObject exploded) are similar, but still different in subtle ways. This new implementation doesn't try as hard to share code between the implementations, so might at first sight appear to duplicate code. The original implementation had many methods with many configuration parameters and utility methods with a high cyclomatic complexity, which made it very hard to reason about. We did away with that. While there, I also made some minor improvements to the serialization path, which allows cleaner round-tripping tests. ### Result A more maintainable and more correct URI decoder/parser implementation. ### Test Plan Added many more unit tests that test the full matrix of supported styles and inputs. --------- Co-authored-by: Si Beaumont <simonjbeaumont@gmail.com>
Improved encoding of NSNumber in OpenAPIValueContainer (#110) Improved encoding of NSNumber in OpenAPIValueContainer ### Motivation When getting CoreFoundation/Foundation types, especially numbers, they automatically bridge to Swift types like Bool, Int, etc. That casting is pretty flexible, and allows e.g. casting a number into a boolean, which isn't desired when encoding into JSON, as `false` and `0` represent very different values. Previously, we relied on the automatic casting to know how to encode values, however that produced incorrect results in some cases. ### Modifications Add explicit handling of CF/NS types and try to encode using that new method before falling back to testing for native Swift types. This ensures that the original intention of the creator of the CF/NS types doesn't get lost in encoding. ### Result Correct encoding into JSON of types produced in the CF/NS world, like JSONSerialization. ### Test Plan Added unit tests. Reviewed by: simonjbeaumont Builds: ✔︎ pull request validation (5.10) - Build finished. ✔︎ pull request validation (5.9) - Build finished. ✔︎ pull request validation (5.9.0) - Build finished. ✔︎ pull request validation (api breakage) - Build finished. ✔︎ pull request validation (docc test) - Build finished. ✔︎ pull request validation (integration test) - Build finished. ✔︎ pull request validation (nightly) - Build finished. ✔︎ pull request validation (soundness) - Build finished. #110
[Runtime] Add support of deepObject style in query params (#100) ### Motivation The runtime changes for: apple/swift-openapi-generator#259 ### Modifications Added `deepObject` style to serializer & parser in order to support nested keys on query parameters. ### Result Support nested keys on query parameters. ### Test Plan These are just the runtime changes, tested together with generated changes. --------- Co-authored-by: Honza Dvorsky <honza@apple.com>
Set content length in request/response bodies (#96) ### Motivation A surprising oversight, we were never setting the `content-length` header when sending out a known-length body. Some transports might be already doing this, but this change makes things more consistent. ### Modifications Add the `content-length` header when setting a body and we know the length from the `HTTPBody`. ### Result More consistent experience. ### Test Plan Adapted unit tests.
Bug/502 crash thread safety fix (#95) ### Motivation Fixes apple/swift-openapi-generator#502 - Ensure thread safety of `HTTPBody.collect(upTo)`. - `makeAsyncIterator()`: Instead of crashing, return AsyncSequence which throws `TooManyIterationsError` thereby honoring the contract for `IterationBehavior.single` (HTTPBody, MultipartBody) ### Modifications - HTTPBody, MultipartBody: `makeAsyncIterator()`: removed `try!`, catch error and create a sequence which throws the error on iteration. - This removed the need for `try checkIfCanCreateIterator()` in `HTTPBody.collect(upTo)`. **Note**: This creates a small change in behavior: There may be a `TooManyBytesError` thrown before the check for `iterationBehavior`. This approach uses the simplest code, IMO. If we want to keep that `iterationBehavior` is checked first and only after that for the length, then the code needs to be more complex. - Removed `try checkIfCanCreateIterator()` in both classes (only used in `HTTPBody`). ### Result - No intentional crash in `makeAsyncIterator()` anymore. - Tests supplied as example in apple/swift-openapi-generator#502 succeed. ### Test Plan - Added check in `Test_Body.testIterationBehavior_single()` to ensure that using `makeAsyncIterator()` directly yields the expected error. - Added tests to check iteration behavior of `MultipartBody`. --------- Co-authored-by: Lars Peters <software@lpeters.net>
PreviousNext