Right, so we’re trying to automate Architect flow publishing with Pulumi - TypeScript, naturally. Been doing this for ages, generally fine. But we’ve hit a weird one. Flows are deploying fine locally, but when pushing to our CI/CD pipeline (GitHub Actions, EU-West region) they consistently fail to publish with a 400 Bad Request - specifically a ‘validation error’.
-
The error message is… verbose. It complains about a missing or invalid reference to a shared data object. The data object itself exists, verified in the GC UI and via direct API calls, and is referenced in the flow’s JSON. It’s just… like the SDK isn’t resolving the reference properly during the publish operation.
-
The core issue seems to stem from stack references. We’re using a separate stack to manage the shared data objects and then referencing them by name from the flow’s stack. It works perfectly when the flow is deployed from the local machine. When the pipeline runs, the flow definition gets passed to the
genesys.architect.Flowresource, which then tries to publish.
Here’s a simplified snippet of the flow resource definition:
const myFlow = new genesys.architect.Flow("my-flow", {
name: "My Flow",
description: "Test Flow",
dataObjects: [{
id: sharedDataObject.id,
}],
// ... other flow properties
});
-
sharedDataObjectcomes from anOutputof a separate stack. It’s a simple string representing the data object ID. When inspecting the Pulumi state in the CI/CD run, thesharedDataObject.idvalue looks correct - the ID is resolvable, but the API is still rejecting it. -
We’ve confirmed the GC API version being used is current (v2). We’ve tried different authentication methods (API keys, OAuth) - no change. We’ve even gone down the rabbit hole of checking the timestamp of the Pulumi state file vs. the last modified date of the shared data object. No obvious skew there.
-
The pipeline isn’t doing anything fancy with the flow definition before publishing, just passing the generated JSON to the SDK. It’s really weird. Feels like the SDK’s resolution of stack references isn’t working consistently in a CI/CD environment.
edit: Just checked the network logs more closely. The request payload being sent to /api/v2/architect/flows does contain the correct data object ID. It’s not a serialization issue. The API is just rejecting it.