Description of issue:
lightspeed-agentic-operator would benefit from allowing custom timeouts w.r.t skill runtime (in our case 10-15 mins). The Agent.spec.timeouts fields (analysisSeconds, executionSeconds, verificationSeconds) are defined on the CRD and the sandbox runtime honors timeout_ms in the request body, but the controller never connects them. The HTTP client uses a hardcoded 5-minute timeout regardless of Agent CR configuration.
Where the gap is:
NewAgentHTTPClient ignores per-step timeouts — client.go#L82-L92:
func NewAgentHTTPClient(endpoint string) AgentHTTPClientInterface {
return &AgentHTTPClient{
httpClient: &http.Client{
Timeout: 5 * time.Minute, // hardcoded
TimeoutMs is defined on the request struct but never populated — client.go#L33:
TimeoutMs *int64 `json:"timeout_ms,omitempty"`
This causes the following,
- Configured timeouts longer than 5m are silently truncated
- Configured timeouts shorter than 5m are silently ignored — resources held until the hardcoded deadline
- The sandbox receives no timeout_ms, so it cannot gracefully wind down before the operator drops the connection
Description of issue:
lightspeed-agentic-operator would benefit from allowing custom timeouts w.r.t skill runtime (in our case 10-15 mins). The Agent.spec.timeouts fields (analysisSeconds, executionSeconds, verificationSeconds) are defined on the CRD and the sandbox runtime honors timeout_ms in the request body, but the controller never connects them. The HTTP client uses a hardcoded 5-minute timeout regardless of Agent CR configuration.
Where the gap is:
NewAgentHTTPClient ignores per-step timeouts — client.go#L82-L92:
TimeoutMs is defined on the request struct but never populated — client.go#L33:
This causes the following,