Problem/Motivation
Drupal\http_client_manager\Plugin\Action\Command::execute currently passes configuration values to Guzzle as raw strings. If the Guzzle Service Description expects a string, this works fine, but if it expects a different schema type such as array then there is a mismatch between the schema type passed by http_client_manager and the schema type required by the API request. In my case I am using ECA tokens but the same schema type mismatch issue arises without ECA.
This prevents users from using ECA to automate any API that requires list-based parameters (like Cloudflare's files, tags, or hosts purges) without writing custom PHP actions.
Steps to reproduce
Example - my_api_module/src/api/cloudflare.json :
1 "PurgeUrls": {
2 "httpMethod": "POST",
3 "uri": "zones/{zone_id}/purge_cache",
4 "parameters": {
5 "files": {
6 "location": "json",
7 "type": "array",
8 "items": { "type": "string" },
9 "description": "An array of URLs to purge."
10 }
11 }
12 }
1. User enters an ECA token (e.g., [node:url:absolute]) into the files parameter.
2. The token resolves to a single string: "https://example.com/page-1".
3. Because the module passes this value as a string instead of a PHP array, the resulting JSON payload is a string:
{"files": "https://example.com/page-1"}
4. Result: The API request fails because the Cloudflare API expects an array:
{"files": ["https://example.com/page-1"]}
---
Proposed resolution
Update Drupal\http_client_manager\Plugin\Action\Command::execute to be "type-aware" of the different JSON types used in the Guzzle Service Description and if necessary to convert raw strings to other schema types such as array before passing the values to Guzzle. For example, when a .json file defines a parameter as type: array, the resolved string should be automatically converted to a PHP array (via comma-splitting or json_decode) before being passed to the Guzzle client. This ensures the final JSON payload matches the API's requirements and prevents requests from being mangled or rejected.
Ensure that tokens are resolved within the execute method to support context-aware tokens (like [node:...]) that require the entity object passed by ECA.
Does this sound right? If yes, I could submit an MR for src/Plugin/Action/Command.php
Comments
Comment #2
juc1 commented