[management] Fix L4 service creation deadlock on single-connection databases#5779
[management] Fix L4 service creation deadlock on single-connection databases#5779
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughRefactors L4 port handling to precompute cluster custom-port capability outside DB transactions and forces L4 targets to be treated as enabled during validation; passes the precomputed capability into L4 port validation/assignment across service creation and update flows. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant Manager
participant ClusterCap as ClusterCapabilityService
participant DB as Database
Client->>Manager: create/update L4 service request
Manager->>ClusterCap: ClusterSupportsCustomPorts(cluster) (precompute)
ClusterCap-->>Manager: customPorts (bool)
Manager->>DB: ExecuteInTransaction(persist/modify service) with customPorts
DB-->>Manager: transaction result
Manager-->>Client: response
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@management/internals/modules/reverseproxy/service/manager/manager.go`:
- Around line 530-536: The bug is that customPorts is computed before
executeServiceUpdate resolves the effective cluster, so clusterCustomPorts may
use an empty or stale cluster and cause ensureL4Port to make wrong decisions; in
persistServiceUpdate, delay computing customPorts until after
executeServiceUpdate has determined service.ProxyCluster (i.e., after
executeServiceUpdate returns or by resolving the effective cluster first), then
call clusterCustomPorts with the resolved cluster and pass that into
ensureL4Port/other checks; update references to clusterCustomPorts,
executeServiceUpdate, ensureL4Port, and service.ProxyCluster/serviceUpdateInfo
so the capability check uses the actual target cluster rather than the
precomputed value.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 41790b8c-44e0-448c-9378-ddf16a0cf9d6
📒 Files selected for processing (2)
management/internals/modules/reverseproxy/service/manager/manager.gomanagement/internals/modules/reverseproxy/service/service.go
|



Describe your changes
Creating an L4 (TCP/UDP/TLS) reverse proxy service hangs indefinitely on deployments using SQLite.
ensureL4Portqueries the proxies table viaClusterSupportsCustomPortsthrough the main DB handle while inside a transaction that already holds the single SQLite connection, causing a self-deadlock. The request blocks until the 5-minute transaction timeout, then returns 500.enabled=trueduring validation, since per-target disable is meaningless for single-target L4 services and the Go zero value (false) causes empty proto mappingsIssue ticket number and link
Stack
Checklist
Documentation
Select exactly one:
Docs PR URL (required if "docs added" is checked)
Paste the PR link from https://github.com/netbirdio/docs here:
https://github.com/netbirdio/docs/pull/__
Summary by CodeRabbit