x/tools/telemetry: i/o timeout reading from telemetry.go.dev

[adonovan]

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.

[cherrymui]

cc @golang/telemetry

[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.

[findleyr]

@adonovan increase your dial timeout?

[adonovan]

For better or worse, cmd/stacks uses http.DefaultClient, which has no timeout.

[findleyr]

The default transport has a 30s dial timeout. That's where your error is coming 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.

[gopherbot]

Change https://go.dev/cl/680397 mentions this issue: cmd/stacks: increase DialTimeout