Queue Metrics - intermittent data action failures

Okay, so we’re hitting this weird one.
The data action - in Architect - is failing intermittently with a 400 Bad Request.
It’s supposed to be simple - pull queue stats and POST them to an internal endpoint.
We’re using the platform API to get the stats - querying for action aggregates via /api/v2/analytics/actions/aggregates/query - then the data action sends that data out.

The data action’s request body is built by concatenating strings.
It’s a straightforward JSON payload - nothing fancy.
It’s failing maybe 1 in 10 times.
The logs in the data action don’t give much - just the 400.
The internal endpoint is working FINE when we test it directly with Postman.
SO, it’s something to do with the data action itself or the data it’s sending.

Here’s what we’ve tried.

• Queue ID is definitely valid.
• Data action’s authentication is set up with the correct OAuth client.
• We’ve checked the JSON payload being constructed in the data action - it looks valid.
• SvelteKit server route version is 2.0.6 - we haven’t changed anything recently.
• Tried different intervals for the data action.
• Checked the Architect flow versioning - it’s the latest.
• +1 to thinking it’s not Terraform.

The weird part is, if we log the response from the queue metrics API before the data action, it’s ALWAYS valid JSON. It’s only when the data action attempts to POST it that things fall apart. I REALLY need to understand why it’s sometimes building a bad request.

The intermittent 400 errors suggest a subtle mismatch between the expected payload structure and what the data action is actually producing - think of it as attempting to fit a square peg into a round hole. The Platform API, like most RESTful services, is unforgiving.

Specifically, I suspect the issue lies within the content type header. The endpoint for querying action aggregates expects a application/json body, but a concatenated string might not automatically set the correct header.

To correct this, ensure the data action explicitly sets the Content-Type header to application/json. You can accomplish this using the Request.headers object in the data action script. For example:

Request.headers['Content-Type'] = 'application/json';

inspect the error response body for clues. A full error response should delineate the specific field that failed validation. Documenting the error responses will help with debugging. Here’s a table to help categorize the failures:

Consider using a JSON validator to confirm the payload conforms to the expected schema. RFC 7159 details the formal specification of JSON.