Ran into a weird issue today with our messaging engagement metrics desync during BYOC trunk failover in Architect. We operate 15 BYOC trunks across the Asia/Singapore region, and while voice failover logic is stable, the digital channels linked to these trunks via channelId mappings are throwing off our analytics. Specifically, when a call fails over from our primary carrier to the secondary BYOC trunk, the conversationId persists, but the channelMetadata injected into the Architect flow via the Get Conversation Details block seems to retain the primary trunk’s SIP credentials instead of updating to the secondary. This causes the custom attribute trunk_origin to incorrectly report TRUNK_PRIMARY_A even when the SIP trace clearly shows the media path switched to TRUNK_SECONDARY_B. The issue manifests in the /api/v2/analytics/conversations/details/query endpoint where the carrierName field mismatches the actual routing path. We are using the latest Architect version and Python SDK 2.1.8 for our reporting scripts. The SIP registration state shows REGISTERED for both trunks, but the failover event triggers a 408 Request Timeout on the initial SIP INVITE before retrying, which seems to delay the metadata update. Is there a known latency in how Genesys Cloud propagates trunk switch events to the digital channel metadata? We need this data to be accurate for our SLA reporting, as currently, 15% of our failover conversations are misattributed in the dashboard. The debugLevel in the SIP trace shows no errors, just the timestamp mismatch between the INVITE retry and the metadata injection. Any insights on forcing a metadata refresh or a workaround in the Architect flow to capture the actual active trunk at the moment of message delivery would be greatly appreciated.