Twice today I have run cmd/stacks and seen it fail like so:
xtools$ stacks
stacks: Error reading reports: error on GET https://telemetry.go.dev/data/2025-06-08: Get "https://telemetry.go.dev/data/2025-06-08": dial tcp 34.149.96.102:443: i/o timeout
The new telemetry.go.dev facade endpoint is much less reliable than the old storage bucket endpoint. Perhaps cloudarmor's DoS detection is triggering spuriously.
Comment From: cherrymui
cc @golang/telemetry
Comment From: adonovan
Happened again twice today. It seems to have gone from ~100% reliable to about ~50%.
Edit: actually even less than 50%. Weirdly, visiting the failing URL in Chrome reliably works: I've never seen it fail. This supports the idea that the user-agent string or some other ambient context is changing the disposition of Cloud Armor.
Comment From: findleyr
@adonovan increase your dial timeout?
Comment From: adonovan
For better or worse, cmd/stacks uses http.DefaultClient, which has no timeout.
Comment From: findleyr
The default transport has a 30s dial timeout. That's where your error is coming from.
Comment From: adonovan
Good point; I can never remember the order in which the matryoshka doll of http.Client configuration is to be assembled.
Perhaps at my age time passes more quickly but I think it failed in less than 30s, so I'll hold off on merging the fix in https://go.dev/cl/680397 until I can observe it one more time.
Comment From: gopherbot
Change https://go.dev/cl/680397 mentions this issue: cmd/stacks: increase DialTimeout