chore(api): disable request timeout#2156
Merged
Merged
Conversation
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix prepared a fix for the issue found in the latest run.
- ✅ Fixed: Removing request timeout risks indefinite handler blocking
- Restored the RequestTimeout middleware by uncommenting both the requestTimeout constant and the middleware registration, preventing indefinite handler blocking during DB/gRPC calls.
Or push these changes by commenting:
@cursor push 0920ca2bd3
Preview (0920ca2bd3)
diff --git a/packages/api/main.go b/packages/api/main.go
--- a/packages/api/main.go
+++ b/packages/api/main.go
@@ -59,7 +59,7 @@
// Must be less than maxWriteTimeout so the context cancels before the
// server's write deadline kills the connection (WriteTimeout does NOT
// cancel r.Context(); see https://github.com/golang/go/issues/59602).
- // requestTimeout = 60 * time.Second
+ requestTimeout = 60 * time.Second
// This timeout should be > 600 (GCP LB upstream idle timeout) to prevent race condition
// https://cloud.google.com/load-balancing/docs/https#timeouts_and_retries%23:~:text=The%20load%20balancer%27s%20backend%20keepalive,is%20greater%20than%20600%20seconds
@@ -129,7 +129,7 @@
},
}),
gin.Recovery(),
- // customMiddleware.RequestTimeout(requestTimeout), //nolint:contextcheck // Gin middleware sets context via c.Request.WithContext
+ customMiddleware.RequestTimeout(requestTimeout), //nolint:contextcheck // Gin middleware sets context via c.Request.WithContext
)
corsConfig := cors.DefaultConfig()This Bugbot Autofix run was free. To enable autofix for future PRs, go to the Cursor dashboard.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2144d21c85
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
dobrac
approved these changes
Mar 18, 2026
levb
added a commit
that referenced
this pull request
Mar 18, 2026
Incorporate main commits: #2150 (validate specified IPs in egress), #2156 (disable request timeout), #2154 (envd init logs), #2151 (storage cache test fix). Resolve conflict in sandbox_create.go by consolidating validation: Egress validation — matches main #2150 + port rejection: - validateEgressRules stays in sandbox_create.go (same location as main) - Uses IsSpecifiedIPOrCIDR from #2150 to reject unspecified addresses (0.0.0.0, ::, 0.0.0.0/24, etc.) while allowing 0.0.0.0/0 - Uses ParseAddressesAndDomains to separate IPs from domains (same as main) - Adds port rejection (egress doesn't support port-specific rules) Ingress validation — new, added next to validateEgressRules: - validateIngressRules + validateIngressEntry in sandbox_create.go - Uses SplitHostPort to separate CIDR from port, validates each part - Uses IsSpecifiedIPOrCIDR for IPv4 + allows ::/0 for IPv6 block-all - Uses ParsePortRange for port/port-range validation - Rejects domains (ingress is IP/CIDR only) - Requires deny-all when allow rules are present Simplify rule.go — remove ParseRule/ParseRules: - Egress validation uses IsSpecifiedIPOrCIDR + ParseAddressesAndDomains directly - Ingress validation uses SplitHostPort + IsIPOrCIDR + ParsePortRange directly - Keep: Rule/ACL structs (hot-path matching), SplitHostPort, ParsePortRange (public) make[1]: Entering directory '/home/lev/dev/infra/iac/provider-gcp' - Remove: ParseRule, ParseRules (tried to be one-size-fits-all, added complexity) Simplify orchestrator ACL building: - newEgressACL: uses parseCIDRs (direct net.ParseCIDR, no ParseRules) - newIngressACL/parseIngressRules: unchanged (builds from proto fields) Update create_instance.go: - buildEgressConfig: uses IsIPOrCIDR for domain detection (was ParseRule) - parseIngressRules: uses SplitHostPort + ParsePortRange (was ParseRule) Test updates: - Error messages updated to match main's IsSpecifiedIPOrCIDR style - Integration tests: replace ::/1/0.0.0.0/1 with ::/0/0.0.0.0/0 (unspecified network addresses now rejected) - TestIsSpecifiedIPOrCIDR preserved from #2150 - TestSplitHostPort, TestParsePortRange replace TestParseRule/TestParseRules
ValentaTomas
pushed a commit
that referenced
this pull request
May 4, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.


Note
Medium Risk
Removing per-request context deadlines can allow handlers to block indefinitely (e.g., on DB pool acquisition), increasing the risk of goroutine buildup and degraded availability under load. It also shifts timeout behavior to upstream/proxy and server write deadlines, which may be less predictable for long-running requests.
Overview
Disables the API’s per-request context timeout by commenting out the
requestTimeoutconstant and thecustomMiddleware.RequestTimeout(...)Gin middleware, so requests no longer get an enforced 60s cancellation/408 behavior and may run until other server or upstream timeouts intervene.Written by Cursor Bugbot for commit 2144d21. This will update automatically on new commits. Configure here.