[Generator] Add headerFields and body to UndocumentedPayload

[czechboy0]

Motivation

Fixes #299.

Depends on apple/swift-openapi-runtime#90 landing first and getting released, and the version dependency being bumped here.

Runtime dependency bumped to 1.1.0.

Modifications

Adapted to the runtime changes, added headerFields and body properties to UndocumentedPayload.

Now, the generated code actually also forwards the values to it.

Result

Easier access to the raw response data if an undocumented response is returned.

Test Plan

Adapted snippet and file-based reference tests, and also the unit tests of the generated code (PetstoreConsumerTests).

[groue]

Thank you @czechboy0, this is a much welcome addition :-)

I guess it is the change to Translator/ClientTranslator/translateClientMethod.swift that fills the undocumented payload with the response headers and body, although I don't quite understand how it works 😅

I'm not sure I understand what's in the response body of the undocumented payload, though. But that's only because I don't understand exactly when .undocumented is returned.

I assume that the response body was not fully buffered, since this would create a risk of high memory consumption.

I thus assume that not a single byte of response body was consumed, otherwise it would throw TooManyIterationsError when touched, and the undocumented payload would be unusable.

Hence the undocumented payload is only returned based on the headers of the response, and this will never change in the future. All unexpected data in the response body itself will never return .undocumented, but some kind of decoding error, and this is a strong contract of the library.

Do I understand well? If so, I'm very happy with this PR!

EDIT. Yes, that's exactly how UndocumentedPayload is documented. 👍

[czechboy0]

I don't understand exactly when .undocumented is returned.

For example, if you OpenAPI document defines responses for 200, 400, and 500, and you receive 401, you'll get an .undocumented case, with the associated status value saying 401. And now, the payload (the second associated value) will contain the header fields and the body stream.

I assume that the response body was not fully buffered, since this would create a risk of high memory consumption.

Correct, HTTPBody is an async sequence of byte chunks, and it's up to the ultimate consumer of this data to start pulling from there. So this change still doesn't lead to any buffering.

Hence the undocumented payload is only returned based on the headers of the response, and this will never change in the future. All unexpected data in the response body itself will never return .undocumented, but some kind of decoding error, and this is a strong contract of the library.

Yes, exactly. The response HTTP status code is how we decide the handling. If the status code is undocumented, you get the raw data. If it's documented, we unwrap the way that the OpenAPI document tells us. If you receive a documented response, but with body data that don't fit the documented structure, an error will be thrown.

Do I understand well? If so, I'm very happy with this PR!

I believe so - please just confirm again that the above fits well with your understanding 🙂

[groue]

Perfect! This was a quick win, enabled by a good initial design (the smoothest butter developers can dream of) 🙂👍