-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(ffi): shared processing of body #456
Conversation
b0601d5
to
a8c4961
Compare
a8c4961
to
b44a80c
Compare
b44a80c
to
fa3be03
Compare
Fixed the issue with the failing tests. Reason being that the
Before merging, I just want to update the docstring to make sure it lines up with the behaviour. |
The logic of processing the body within the `pactffi_with_body` was not consistent across the various interaction types. This refactors the logic out into a separate `process_body` function. Note that as a result of this change, the behaviour of the FFI _may_ change. Signed-off-by: JP-Ellis <[email protected]>
fa3be03
to
82dc1c0
Compare
Docstring has been updated. @rholshausen, I'll leave you do a last check before merging 👍 |
I believe this change has possibly caused a regression in the pact-php compat and test suite, see mentioned PR. Changes also consumed in following PR's. There are xml tests in pact-js but they are only consumable on release of pact-js-core (unless locally tested) |
Hmm, I was worried this change may have unintended repercussions, though was relieved to see the test suite to pass... Evidently an edge case was not covered. I'll have a look at the PR that uncovered this unintended change, though given neither Pact Go or Pact JS picked up this issue, I'm wondering whether Tien may have unintentionally baked in the broken behaviour into a test? Once I've figured out exactly the extent of the change, I'll update the changelog to highlight this change in behaviour in case it impacts anyone else in the future. EDIT: So I have had a quick look at the way the tests/examples are implemented, and it appears that the XML description is built from scratch, and then encoded into JSON before being passed through the FFI. The logic implemented should detect the JSON content and parse it as before though. But let me dig into that a bit more later. |
Ahh so I don't believe pact-js-core or pact-go covered it. I think the detect content type from string is saying its application/json and it isn't being transformed into xml I think its this bit of code And I believe that we need to check if its actually xml, when intermediate json is detected |
The logic should be fine. There's two content types set at the start of that function:
pact-reference/rust/pact_ffi/src/mock_server/handles.rs Lines 1682 to 1687 in 111a18c
The main matching is done on the
Then if that is XML, it checks if the body is JSON, and fallbacks to raw body parsing: pact-reference/rust/pact_ffi/src/mock_server/handles.rs Lines 1707 to 1729 in 111a18c
I'm also confused as to why the XML test within the FFI test suite passed, by the PHP one did not, as the one in this repo also uses the JSON body: pact-reference/rust/pact_ffi/tests/tests.rs Lines 478 to 535 in 111a18c
I would need to enable trace-level logging and run the Pact PHP tests to properly understand that is going on. |
The logic of processing the body within the
pactffi_with_body
was not consistent across the various interaction types. This refactors the logic out into a separateprocess_body
function.Note that as a result of this change, the behaviour of the FFI may change.