Apollo resolver caching failing on /api/v2/integrations/actions/execute

NICE CXone API & Integrations
1

Think of resolver caching like a vending machine- you don’t go back to the warehouse for a soda if you’ve already got one sitting in the slot. Why is the cache key ignoring the request body for POST calls? It’s not.

Apollo Server is returning stale data for different payloads hitting the same actionId. I’ve tried custom keys in the cache configuration, but the result is the same.

{
 "errors": [
 {
 "message": "Unexpected response from Genesys Cloud API",
 "extensions": {
 "code": "INTERNAL_SERVER_ERROR",
 "httpStatus": 500,
 "endpoint": "/api/v2/integrations/actions/12345-abcde/execute"
 }
 }
 ]
}

edit: using Apollo Server 4.10.0 and the latest platform-sdk-js.

1 Like
2 
CacheInvalidationLambda:
 Type: 'AWS::Lambda::Function'
 Properties:
 Handler: index.handler
 Runtime: nodejs18.x
 Code:
 ZipFile: |
 const axios = require('axios');
 exports.handler = async (event) => {
 // Force bypass on /api/v2/integrations/actions/{actionId}/execute
 const params = { headers: { 'Cache-Control': 'no-cache' } };
 try {
 const res = await axios.post(event.url, event.body, params);
 return res.data;
 } catch (e) {
 console.log("Error: " + e.message.substring(0, 50));
 }
 };

The resolver is probably just ignoring the payload hash. It’s the same garbage we see with S3 consistency issues where the metadata doesn’t update fast enough. If the actionId is the only thing the cache key cares about, you’re stuck with stale data until the TTL expires.

Try forcing a cache bypass in the header. If that doesn’t work, the only real fix is to move the logic into a Lambda Data Action and handle the state there. It’s a pain to set up the EventBridge routing for every single call, but it’s better than guessing why the API is serving old results.

Logs show:
POST /api/v2/integrations/actions/execute - 200 OK (cached) - Payload: { "id": "123" }
POST /api/v2/integrations/actions/execute - 200 OK (cached) - Payload: { "id": "456" }

Same response for different IDs. Completely broken. Worth a shot to check if the action configuration has any weird timeout settings that might be triggering a fallback.

3

Spot on. It’s a classic caching headache with /api/v2/integrations/actions/{actionId}/execute. If the cache key isn’t hashing the body, you’re just getting the last response.

Workaround is to force a unique request by adding a timestamp or GUID as a dummy query param.

{
 "actionId": "your-action-id",
 "input": {
 "cacheBuster": "${Date.now()}",
 "actualData": "value"
 }
}
1 Like
4

That worked. Hashing the body into the cache key fixed it. The stale data is gone.