PlannerGenerator agent executor fails with streamGenerateContent timeouts (syscall.ETIMEDOUT)

Google Antigravity
1

Problem Description

During long-running agent execution tasks on macOS, the AgentExecutor loop encounters a hard failure during streaming generation requests to the backend endpoint.

Initially, this manifested as an ephemeral port exhaustion issue (syscall.EADDRNOTAVAIL / “can’t assign requested address”). After broadening the local ephemeral port range (net.inet.ip.portrange.first=10240), the error evolved into a definitive connection read timeout (syscall.ETIMEDOUT / “operation timed out”).

The telemetry metrics show that the client has received zero tokens before terminating:
tags: map[stream_receive_count:0 streaming_duration:0s]

This suggests that the client-side http.Client timeout or the parent context.Context deadline is configured too strictly, failing to account for longer model processing/thinking windows before the initial stream chunk is dispatched by daily-cloudcode-pa.googleapis.com.

Environment

  • OS: macOS
  • Component: google3/third_party/gemini_coder/framework/generator/planner_generator.go
  • Target Endpoint: v1internal:streamGenerateContent?alt=sse

Log Stack Trace

Error: agent executor error: request failed: Post "[https://daily-cloudcode-pa.googleapis.com/v1internal:streamGenerateContent?alt=sse](https://daily-cloudcode-pa.googleapis.com/v1internal:streamGenerateContent?alt=sse)": read tcp 10.12.129.220:52308->216.239.36.223:443: read: operation timed out
Wraps: (4) attached stack trace
  -- stack trace:
  | google3/third_party/gemini_coder/framework/generator/generator.(*streamResponseHandler).processStream
  | 	third_party/gemini_coder/framework/generator/stream_handler.go:339
  | google3/third_party/gemini_coder/framework/generator/generator.(*PlannerGenerator).attemptGenerate
  | 	third_party/gemini_coder/framework/generator/planner_generator.go:452
  | google3/third_party/gemini_coder/framework/generator/generator.(*PlannerGenerator).generateWithAPIRetry
  | 	third_party/gemini_coder/framework/generator/planner_generator.go:287
  | google3/third_party/gemini_coder/framework/generator/generator.(*PlannerGenerator).generateWithModelOutputRetry
  | 	third_party/gemini_coder/framework/generator/planner_generator.go:149
  | google3/third_party/gemini_coder/framework/generator/generator.(*PlannerGenerator).Generate
  | 	third_party/gemini_coder/framework/generator/planner_generator.go:87
  | google3/third_party/flux/executor/executor.(*Executor).runInvocation
2

solid diagnosis, sounds like the client side context deadline is too tight for cases where the model takes a while to emit the first token, rather than a real network problem on your end, especially since you already ruled out port exhaustion. worth also checking if youre behind a proxy or vpn that could be adding latency to that first byte. since you already tagged it as a bug, this level of detail should make it easy for the antigravity team to reproduce.

3

Great suggestion, I can confirm on a short session that without my VPN, Antigravity is behaving normally. It would be great if the team could mitigate this issue but I have a workaround now.

4

best part about tinkering with AI these days, we have a plethora of workarounds. :wink: