You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the DefaultMessageEncoderStream in smithy-swift's ClientRuntime has requestEncoder: RequestEncoder property. In protocols that use JSON, this field is populated by the encoder property of the client object.
Code path for an event streaming operation:
The encoder (JSONEncoder) is saved to middleware context when the context is built (example)
The saved encoder is fetched from middleware context in EventStreamBodyMiddlewarehere.
Then, that encoder is passed to DefaultMessageEncoderStream and is used to parse Event into EventStream.Messagehere.
However, following the XML serde refactor that got rid of 3rd party XML library that uses Codable conformances, encoder and decoder are no longer properties of XML service clients, meaning event streaming operation for an XML protocol would fail due to missing request encoder.
Why was this not caught?
For event stream input, it is because currently no AWS service uses XML & event stream input combo.
For event stream output, the reason why no warnings were thrown is because we do not have integration test for the one operation that uses XML AND event stream output, which is S3:SelectObjectContentEventStream.
Task
Investigate if event streaming input and output behaves as it should for restXml protocol
Implement support based on the findings.
Create an integration test for S3:SelectObjectContentEventStream.
The text was updated successfully, but these errors were encountered:
sichanyoo
changed the title
Investigate event streaming support for protocols that use XML (e.g., restXml)
Event streaming support for protocols that use XML (e.g., restXml)
Mar 8, 2024
Background
Currently, the
DefaultMessageEncoderStream
in smithy-swift's ClientRuntime hasrequestEncoder: RequestEncoder
property. In protocols that use JSON, this field is populated by the encoder property of the client object.Code path for an event streaming operation:
EventStreamBodyMiddleware
here.DefaultMessageEncoderStream
and is used to parseEvent
intoEventStream.Message
here.However, following the XML serde refactor that got rid of 3rd party XML library that uses Codable conformances, encoder and decoder are no longer properties of XML service clients, meaning event streaming operation for an XML protocol would fail due to missing request encoder.
Why was this not caught?
For event stream input, it is because currently no AWS service uses XML & event stream input combo.
For event stream output, the reason why no warnings were thrown is because we do not have integration test for the one operation that uses XML AND event stream output, which is S3:SelectObjectContentEventStream.
Task
The text was updated successfully, but these errors were encountered: