Command that triggered the bug
apiops extract --log-level debug --resource-group --service-name --output ./artifacts --filter ./configuration.extractor.yaml --subscription-id --remove-stale
Expected behavior
Extraction completes with exit code 0 for an API whose policy uses set-body template="liquid" to build or transform a request/response body, as long as the API and its real named values/backends actually exist and are reachable.
Actual behavior
The extraction otherwise finishes fine. All APIs, operations, and real named values get written to the output directory. But the run still reports errors and exits with code 1:
[INFO] Extraction complete: 19 resources extracted, 4 errors
With --log-level debug on, I can see the CLI issuing GET .../namedValues/<value> requests where <value> isn't a named value at all. It looks like it was pulled straight out of a {{ ... }} expression inside one of our set-body template="liquid"> blocks:
[DEBUG] HTTP GET https://management.azure.com/.../namedValues/context.Request.MatchedParameters%5B%22id%22%5D?api-version=2025-09-01-preview
[DEBUG] HTTP GET https://management.azure.com/.../namedValues/body.envelope.body.Test_Result.test?api-version=2025-09-01-preview
[DEBUG] HTTP GET https://management.azure.com/.../namedValues/body.envelope.body.fault.faultcode?api-version=2025-09-01-preview
[DEBUG] HTTP GET https://management.azure.com/.../namedValues/body.envelope.body.fault.faultstring?api-version=2025-09-01-preview
None of those are named values in our APIM instance. They're Liquid interpolation expressions from a set-body template="liquid" policy we use to build a SOAP request and reshape the SOAP response into JSON. Each lookup 404s, and each 404 seems to get counted toward the "errors" total. That matches up exactly: 4 Liquid expressions, 4 reported errors. The nonzero exit code then fails our CI pipeline step even though nothing is actually broken or missing.
To work around this we rewrote the affected set-body template="liquid"> blocks as plain C# expressions (<set-body>@{ ... return ...; }</set-body>) instead of Liquid templates. That removed the {{ }} syntax from the policy entirely, and the same extraction now completes with 0 errors and exit code 0. But with the Liquid template the policy would be easier to read and understand.
apiops CLI version
1.0.1
Environment details
- Azure DevOps pipeline, Ubuntu 24.04 hosted agent
- Node.js 24.x
apiops extract invoked via npx, with --filter pointing at a YAML filter config- The affected API's policy has three
<set-body template="liquid"> blocks: one building a SOAP request body (interpolating a template parameter), and two transforming the SOAP response into JSON (interpolating values pulled out of the parsed SOAP envelope)
CI/CD environment
Azure DevOps
Is this bug blocking you?
No
Command that triggered the bug
apiops extract --log-level debug --resource-group --service-name --output ./artifacts --filter ./configuration.extractor.yaml --subscription-id --remove-stale
Expected behavior
Extraction completes with exit code 0 for an API whose policy uses
set-body template="liquid"to build or transform a request/response body, as long as the API and its real named values/backends actually exist and are reachable.Actual behavior
The extraction otherwise finishes fine. All APIs, operations, and real named values get written to the output directory. But the run still reports errors and exits with code 1:
With
--log-level debugon, I can see the CLI issuingGET .../namedValues/<value>requests where<value>isn't a named value at all. It looks like it was pulled straight out of a{{ ... }}expression inside one of ourset-body template="liquid">blocks:None of those are named values in our APIM instance. They're Liquid interpolation expressions from a
set-body template="liquid"policy we use to build a SOAP request and reshape the SOAP response into JSON. Each lookup 404s, and each 404 seems to get counted toward the "errors" total. That matches up exactly: 4 Liquid expressions, 4 reported errors. The nonzero exit code then fails our CI pipeline step even though nothing is actually broken or missing.To work around this we rewrote the affected
set-body template="liquid">blocks as plain C# expressions (<set-body>@{ ... return ...; }</set-body>) instead of Liquid templates. That removed the{{ }}syntax from the policy entirely, and the same extraction now completes with 0 errors and exit code 0. But with the Liquid template the policy would be easier to read and understand.apiops CLI version
1.0.1
Environment details
apiops extractinvoked vianpx, with--filterpointing at a YAML filter config<set-body template="liquid">blocks: one building a SOAP request body (interpolating a template parameter), and two transforming the SOAP response into JSON (interpolating values pulled out of the parsed SOAP envelope)CI/CD environment
Azure DevOps
Is this bug blocking you?
No