That’s an interesting issue - the interactionId propagation can be surprisingly fragile, especially with the Client App SDK. It’s not simply a matter of the event firing; there are a few potential points of failure that aren’t immediately obvious. I’ve seen this happen before, and it often comes down to timing and the order in which various components initialize.
Cause:
The genesyscloud.sdk’s onInteraction event is asynchronous. This means the interaction object passed to the event handler might not be fully populated with all properties - including the id - at the exact moment your ‘Launch Client App’ activity triggers. The SDK itself is doing what it’s supposed to be, but the data isn’t immediately available. This is particularly true when the interaction is rapidly transitioning between states, like immediately after a call connects. The underlying integration expects that ID to be present. If it isn’t, the launch will fail or, as you’re seeing, result in intermittent errors. It also appears that the SDK’s internal caching mechanism sometimes delays the id being populated - it isn’t a simple race condition.
Solution:
We ended up using a polling mechanism within the Client App itself to ensure the interactionId is available before attempting to perform any actions that require it. It’s not ideal, but it’s proven to be the most reliable approach. The general idea is to listen for the onInteraction event, store the interaction object, and then periodically check if the interaction.id property is populated.
Here’s a simplified example of how that looks in JavaScript within the Client App:
let interactionObject = null;
genesyscloud.sdk.onInteraction = (interaction) => {
interactionObject = interaction;
checkInteractionId();
};
function checkInteractionId() {
if (interactionObject && interactionObject.id) {
// Interaction ID is available - proceed with your logic
console.log('Interaction ID is available:', interactionObject.id);
// Example: trigger screen pop
launchScreenPop(interactionObject.id);
} else {
// Interaction ID is not yet available - try again later
setTimeout(checkInteractionId, 200); // Check every 200 milliseconds
console.log('Waiting for Interaction ID...');
}
}
function launchScreenPop(interactionId) {
// Your screen pop logic here
console.log('Launching screen pop with Interaction ID:', interactionId);
}
The setTimeout function introduces a delay, allowing the SDK time to fully populate the interaction object. You’ll likely need to adjust the delay based on your environment and network conditions. A delay of 200 milliseconds has worked for us, but it’s worth experimenting.
There’s a risk of introducing latency with this approach, and it’s not a perfect solution, but it resolves the intermittent failures we were seeing. It’s a trade-off between reliability and performance. Alternatively, you could consider modifying the Architect flow to delay the ‘Launch Client App’ activity slightly, but that might introduce other issues if the delay is too long. The key is to ensure the interactionId is available before attempting to use it.