Jira connector: status transitions fail on Cloud with HTTP 400 (expand sent as an array)

[jhuynh-devcups]

On Jira Cloud, the connector returns HTTP 400 when a sync includes status transitions. A sync without transitions works.

$ statewave-connectors sync jira --host https://statewave.atlassian.net \
    --projects TEST --include issues,transitions --dry-run --json
{"error":"jira request failed: 400"}

--include issues and --include issues,comments both succeed. Only the transitions value causes the HTTP 400.

Root cause: the /search/jql migration (the #233 fix) places expand in the request body as a JSON array. Atlassian's POST /rest/api/3/search/jql rejects expand when the connector sends expand as an array. The endpoint requires expand as a comma-separated string. A direct test against the endpoint confirms the two outcomes:

POST /rest/api/3/search/jql  {"jql":"project=TEST","fields":["summary"],"expand":["changelog"],...}
-> 400 {"errorMessages":["Invalid request payload. Refer to the REST API documentation and try again."]}

POST /rest/api/3/search/jql  {"jql":"project=TEST","fields":["summary"],"expand":"changelog",...}
-> 200

The endpoint accepts fields as an array. The endpoint requires expand as a string.

The unit test tests/transitions.test.ts asserts expand: ["changelog"]. The test suite therefore passes, but the live Cloud API returns HTTP 400. Only the change-history request for transitions sets expand. For that reason, the connector still serves issues and comments correctly.

Fix: send expand as a comma-separated string in the /search/jql request body (for example "changelog"), not as a JSON array.

The status-transitions feature was added in #194. The /search/jql migration was introduced by #233. Tested with @statewavedev/connectors-jira 0.4.1 and @statewavedev/connectors-cli 0.4.7 against Jira Cloud statewave.atlassian.net.