refactor: Migrate Network Security Group API handlers to WithTx transaction helper#478
Open
chet wants to merge 1 commit intoNVIDIA:mainfrom
Open
refactor: Migrate Network Security Group API handlers to WithTx transaction helper#478chet wants to merge 1 commit intoNVIDIA:mainfrom
chet wants to merge 1 commit intoNVIDIA:mainfrom
Conversation
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Summary by CodeRabbit
WalkthroughReplace manual SQL transaction handling in NetworkSecurityGroup create/update/delete handlers with ChangesNetworkSecurityGroup Transaction Management Refactor
Sequence Diagram(s)sequenceDiagram
participant Client
participant Handler
participant DB
participant Temporal
Client->>Handler: HTTP Create/Update/Delete request
Handler->>DB: cdb.WithTx / cdb.WithTxResult (enter closure)
DB-->>Handler: tx context
Handler->>DB: insert/update/delete NSG + create status-details
Handler->>Temporal: start synchronous workflow (within closure)
Temporal-->>Handler: workflow result or timeout
DB-->>Handler: commit or rollback (closure returns)
alt workflow timeout detected
Handler->>Temporal: TerminateWorkflowOnTimeOut (scheduled after closure)
end
Handler-->>Client: HTTP response built from closure-captured values
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Comment |
🔐 TruffleHog Secret Scan✅ No secrets or credentials found! Your code has been scanned for 700+ types of secrets and credentials. All clear! 🎉 🕐 Last updated: 2026-05-04 16:58:16 UTC | Commit: 064594a |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
🧹 Nitpick comments (1)
api/pkg/api/handler/networksecuritygroup.go (1)
937-940: 💤 Low valueInconsistent error handling for status detail creation.
In the Create handler (lines 253-256), a failed
sdDAO.CreateFromParamscall returns an error and aborts the transaction. Here in Delete, the error is logged but silently ignored, allowing the deletion to proceed. If this is intentional—treating status detail as non-critical for deletes—consider adding a brief comment to document this design decision; otherwise, align with the Create handler's behavior.💡 Suggested documentation if intentional
// Create status detail + // NOTE: Status detail creation is non-critical for deletes; log and continue. if _, derr := sdDAO.CreateFromParams(ctx, tx, nsg.ID, *cdb.GetStrPtr(cdbm.NetworkSecurityGroupStatusDeleting), cdb.GetStrPtr("received request for deletion, pending processing")); derr != nil { logger.Error().Err(derr).Msg("error creating Status Detail DB entry") }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api/pkg/api/handler/networksecuritygroup.go` around lines 937 - 940, The Delete handler currently calls sdDAO.CreateFromParams and only logs errors while Create handler treats that error as fatal and aborts the transaction; make them consistent by either (A) propagating the error from sdDAO.CreateFromParams in the Delete handler (roll back/abort the current transaction and return the error exactly like the Create handler does), or (B) if the status-detail write is intentionally non-critical on delete, add a concise comment above the sdDAO.CreateFromParams call explaining this design decision so future readers know the difference; reference sdDAO.CreateFromParams, the Delete handler in networksecuritygroup.go, and the Create handler behavior when making the change.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@api/pkg/api/handler/networksecuritygroup.go`:
- Around line 937-940: The Delete handler currently calls sdDAO.CreateFromParams
and only logs errors while Create handler treats that error as fatal and aborts
the transaction; make them consistent by either (A) propagating the error from
sdDAO.CreateFromParams in the Delete handler (roll back/abort the current
transaction and return the error exactly like the Create handler does), or (B)
if the status-detail write is intentionally non-critical on delete, add a
concise comment above the sdDAO.CreateFromParams call explaining this design
decision so future readers know the difference; reference
sdDAO.CreateFromParams, the Delete handler in networksecuritygroup.go, and the
Create handler behavior when making the change.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 32121a4c-e1eb-42a6-8182-d78927e24bf4
📒 Files selected for processing (1)
api/pkg/api/handler/networksecuritygroup.go
🔍 Container Scan Summary
Per-CVE detail lives in the per-service |
chet
force-pushed
the
with-tx-networksecuritygroup
branch
from
064594a to
214a91e
Compare
thossain-nv
changed the title
thossain-nv
reviewed
May 6, 2026
| var timeoutResp func() error | ||
| var ssd *cdbm.StatusDetail | ||
|
|
||
| networkSecurityGroup, err := cdb.WithTxResult(ctx, cnsgh.dbSession, func(tx *cdb.Tx) (*cdbm.NetworkSecurityGroup, error) { |
Contributor
There was a problem hiding this comment.
Any difference between WithTx and using outer scope variable vs calling WithTxResult?
Contributor
Author
There was a problem hiding this comment.
Oh yeah -- that's a lot better -- fixed!
| NetworkSecurityGroupID: nsg.ID, | ||
| Status: cdb.GetStrPtr(cdbm.NetworkSecurityGroupStatusDeleting), | ||
| } | ||
| if _, derr := nsgDAO.Update(ctx, tx, unsgInput); derr != nil { |
Contributor
There was a problem hiding this comment.
Maybe we can detach these as well?
Contributor
Author
There was a problem hiding this comment.
shoot, missed that one -- done, sorry!
chet
force-pushed
the
with-tx-networksecuritygroup
branch
from
214a91e to
b41687c
Compare
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@api/pkg/api/handler/networksecuritygroup.go`:
- Around line 940-945: The StatusDetail creation error is currently only logged
and swallowed after calling sdDAO.CreateFromParams in the delete flow; change
this to fail the surrounding transaction by returning or propagating the error
(derr) so the caller can rollback/abort instead of committing; locate the
sdDAO.CreateFromParams call (using ctx, tx, nsg.ID and
cdbm.NetworkSecurityGroupStatusDeleting) and replace the logger-only path with a
return/propagate of derr (or wrap it with context) consistent with the
create/update error handling.
🪄 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: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: ab031316-39c3-4890-ac47-f25c627cdf52
📒 Files selected for processing (1)
api/pkg/api/handler/networksecuritygroup.go
Applies `WithTx` (and `WithTxResult`!) from NVIDIA#462 to the `Create`/`Update`/`Delete` NSG handlers. Implements our "`timeoutResp` pattern" (which is something we had introduced in NVIDIA#472, and then @coderabbitai said we should be consistent by doing it everywhere). TLDR is the existing code calls `common.TerminateWorkflowOnTimeOut` on timeout, but we want to defer that until after the transaction is unwound + DB connection back (because we don't want it to block waiting on the network). The adjustment (which we've done before, but figured I'd call it out more explicitly here) is effectively: ``` var timeoutResp func() error err = cdb.WithTx(ctx, ..., func(tx *cdb.Tx) error { ... if /* workflow timeout detected */ { // capture the terminate work, but DON'T do it yet timeoutResp = func() error { return common.TerminateWorkflowOnTimeOut(...) } return cutil.NewAPIError(...) // forces rollback } ... }) // rollback has now completed, now we do potentially blocking network work if timeoutResp != nil { return timeoutResp() } ``` Also addressed some @coderabbitai feedback around log messages in advance. Signed-off-by: Chet Nichols III <chetn@nvidia.com>
chet
force-pushed
the
with-tx-networksecuritygroup
branch
from
b41687c to
37f086a
Compare
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
2 participants
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.
Description
Applies
WithTx(andWithTxResult!) from #462 (and now in #472, #473, and #476) to theCreate/Update/DeleteNSG handlers.Implements our "
timeoutResppattern" (which is something we had introduced in #472, and then @coderabbitai said we should be consistent by doing it everywhere). TLDR is the existing code callscommon.TerminateWorkflowOnTimeOuton timeout, but we want to defer that until after the transaction is unwound + DB connection back (because we don't want it to block waiting on the network).The adjustment (which we've done before, but figured I'd call it out more explicitly here) had some discussion in #472 (comment), and is effectively:
Also addressed some @coderabbitai feedback around log messages in advance.
Signed-off-by: Chet Nichols III chetn@nvidia.com
Type of Change
Services Affected
Related Issues (Optional)
Breaking Changes
Testing
Additional Notes