I am trying to decipher this one. Is it normal for the worker to be in a colo and subrequest to fire in a different colo? This is 9,579 km apart.
This worker is an IoT heartbeat (development stage).
Worker in NRT
4c034ec5ebada530-NRT
Subrequest via DUB
4c034ec607eaa530-DUB (162.158.39.7)
I only see this phenomenon on Pro with Argo, but not in Pro accounts. Is there a chaining mechanism or a relay to make the subrequest faster when using Argo?
This is expected with Argo Smart Routing. 4c034ec607eaa530-DUB actually originated in NRT, where the worker ran, but was routed to your origin via DUB. Currently the airport code of the last hop overwrites the originating colo’s airport code – I’m not sure if this is a feature or a bug, though.