|
| 1 | +-- ============================================================================ |
| 2 | +-- Bug #375: REST HttpResponse result handling serialized as string |
| 3 | +-- ============================================================================ |
| 4 | +-- |
| 5 | +-- Symptom (before fix): |
| 6 | +-- When a Studio Pro REST call action bound the complete HTTP response |
| 7 | +-- to an output variable, the parser/AST captured this as |
| 8 | +-- `ResultHandlingHttpResponse` and the action-level |
| 9 | +-- `ResultHandlingType` was `HttpResponse`. The writer, however, did |
| 10 | +-- NOT have an explicit branch for `ResultHandlingHttpResponse` inside |
| 11 | +-- `serializeRestResultHandling`, so it fell through to the string |
| 12 | +-- default. The serialized result variable was emitted as |
| 13 | +-- `DataTypes$StringType`, not the expected |
| 14 | +-- `DataTypes$ObjectType` bound to `System.HttpResponse`. |
| 15 | +-- Studio Pro then surfaced a type mismatch on the bound output |
| 16 | +-- variable, and dependent activities that reached into the response |
| 17 | +-- (`$Response/Content`, `$Response/StatusCode`) failed validation |
| 18 | +-- with CE0117. |
| 19 | +-- |
| 20 | +-- After fix (writer only): |
| 21 | +-- `serializeRestResultHandling` now has an explicit |
| 22 | +-- `ResultHandlingHttpResponse` branch that emits a `DataTypes$ObjectType` |
| 23 | +-- variable type bound to `System.HttpResponse`. |
| 24 | +-- |
| 25 | +-- Scope note — known related gap: |
| 26 | +-- The MDL builder for `rest call ... returns response` still creates |
| 27 | +-- a `ResultHandlingString` (not `ResultHandlingHttpResponse`). See |
| 28 | +-- `mdl/executor/cmd_microflows_builder_calls.go` — the |
| 29 | +-- `case ast.RestResultResponse` arm carries the comment |
| 30 | +-- "we would need a different result type, but using String for now". |
| 31 | +-- That means newly authored MDL with `returns response` does NOT yet |
| 32 | +-- trigger the new writer branch. PR #376 fixes the symptom for |
| 33 | +-- existing Studio Pro models that already contain |
| 34 | +-- `ResultHandlingHttpResponse` in their BSON; the BUILDER side is |
| 35 | +-- tracked separately and verified by the SDK-level Go test |
| 36 | +-- `TestSerializeRestResultHandlingHttpResponseUsesObjectType`, which |
| 37 | +-- constructs the AST directly. |
| 38 | +-- |
| 39 | +-- Usage (positive control): |
| 40 | +-- mxcli exec mdl-examples/bug-tests/375-rest-httpresponse-result-type.mdl -p app.mpr |
| 41 | +-- `mx check` against the resulting MPR must report 0 errors. The |
| 42 | +-- negative case (a Studio Pro REST call with HttpResponse binding) |
| 43 | +-- needs the existing BSON shape and is covered by the Go test above. |
| 44 | +-- ============================================================================ |
| 45 | + |
| 46 | +create module BugTest375; |
| 47 | + |
| 48 | +-- Inline REST call returning a string. Once the builder learns to emit |
| 49 | +-- ResultHandlingHttpResponse for `returns response`, this script can be |
| 50 | +-- updated to use `returns response` and exercise the writer branch end |
| 51 | +-- to end. |
| 52 | +create microflow BugTest375.MF_RestCall () |
| 53 | +returns boolean as $Ok |
| 54 | +begin |
| 55 | + declare $Ok boolean = false; |
| 56 | + |
| 57 | + $Body = rest call get 'https://httpbin.org/get' |
| 58 | + header Accept = 'application/json' |
| 59 | + timeout 15 |
| 60 | + returns string |
| 61 | + on error continue; |
| 62 | + |
| 63 | + if $Body != '' then |
| 64 | + set $Ok = true; |
| 65 | + end if; |
| 66 | + |
| 67 | + return $Ok; |
| 68 | +end; |
| 69 | +/ |
0 commit comments