Studio SNIPPET 409 Conflict when injecting dynamic payload into active messaging session

Is the correct approach to map the conversationId from the REST Proxy response directly into the SNIPPET context, or should the flow route through the realtime analytics endpoint first? The outbound messaging sequence keeps failing when trying to inject a dynamic payload into an active guest session. The environment runs Studio build 2023.11.0, and the REST Proxy action hits POST /api/v2/conversations/messaging with a minimal JSON body. The response comes back clean initially, but the subsequent SNIPPET action throws a 409 Conflict with error_code: "CONVERSATION_NOT_FOUND". It doesn’t make sense since the session was open a second prior.

Breaking down the execution path step by step clarifies where it drops. First, the flow validates the guestId against the CRM payload. Next, that value passes into a custom SNIPPET script via setCustomAttribute("targetGuest", guestId). The script then parses the incoming JSON object and attempts to append a structured message payload. Local testing shows the parsing logic works fine, but deployment to the London prod environment flips the session state to closed before the message queue actually processes it.

A waitFor task holds execution for three seconds, yet the 409 still fires. The REST Proxy headers include Authorization: Bearer <token> and Content-Type: application/json. The response payload looks like this:

{
 "conversationId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
 "state": "open",
 "createdDate": "2023-10-15T14:22:10.000Z"
}

The SNIPPET then attempts POST /api/v2/conversations/messaging/{id}/messages using that exact ID. The gateway returns 409 immediately. Checking the X-Request-Id across the proxy and snippet calls reveals different edge nodes, which explains the state mismatch. Consistent failures appear during the 09:00 GMT rush window.

The flow diagram shows a straight path from REST Proxy to SNIPPET without any conditional splits. Maybe the session token expires between the two calls, or the messaging service requires a separate handshake before accepting injected payloads. The debug logs just repeat Failed to resolve conversation context.