chore: Introduce re-usable teardown function

[PeterSchafer]

Pull Request Submission Checklist

• Follows CONTRIBUTING guidelines
• Commit messages are release-note ready, emphasizing what was changed, not how.
• Includes detailed description of changes
• Contains risk assessment (Low | Medium | High)
• Highlights breaking API changes (if applicable)
• Links to automated tests covering new functionality
• Includes manual testing instructions (if necessary)
• Updates relevant GitBook documentation (PR link: ___)
• Includes product update to be communicated in the next stable release notes

What does this PR do?

This PR refactors the application teardown logic into a re-usable function, so that future changes can be based on it, for example for special case handling like timeout, signals ...

The PR also adds missing support for context in the legacycli workflow.

1. Refactors teardown logic into a dedicated tearDown() function that handles analytics, instrumentation, cleanup, and logging
2. Extracts instrumentation helpers to a new instrumentation.go file for better code organization

Where should the reviewer start?

Start with cliv2/cmd/cliv2/main.go:487-523 for the new tearDown() function, then review the signal handling setup at lines 635-656.

How should this be manually tested?

This is just a refactoring to prepare for future changes, so it should be functionally unchanged.

What's the product update that needs to be communicated to CLI users?

N/A - No user-facing behavior changes.

Risk assessment (Low | Medium | High)?

Low - refactoring only

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[j-luong]

question: if teardown hangs (e.g. when making the analytics API call), can we still SIGINT the process? Or does teardownOnce prevent this? Basically, is it possible to be a hanging state?

[PeterSchafer]

As mentioned before, I'm working on a solution.

[danskmt]

The context ctx here can happen to be already-cancelled as it is derived from the parent context. Testing locally, I saw this issue happening:

Here I suppose you should use a fresh context for tearing down:

teardownCtx, cancel := context.WithTimeout(context.Background(), teardownTimeout)

Also, the context parameter we can use ctxCancel, updating the function signature:
func tearDown(ctx context.Context, ... -> func tearDown(ctxCancel context.CancelFunc, ...

in the calls of tearDown (L664 and L716), we provide ctxCancel:

finalExitCode = tearDown(ctxCancel, signalError, errorListCopy, startTime, ua, cliAnalytics, networkAccess)
...
finalExitCode = tearDown(ctxCancel, err, errorListCopy, startTime, ua, cliAnalytics, networkAccess)

And after sendInstrumentation call (line 516) can terminate child processes:

sendInstrumentation(teardownCtx, globalEngine, cliAnalytics.GetInstrumentation(), globalLogger)
ctxCancel()

i.e. instead of calling ctxCancel in line 655, we do it here after sendInstrumentation, wdyt?

[PeterSchafer]

Thanks @danskmt ! Good catches! I marked the PR as draft as it is far from ready. There are plenty of local changes as well, so I prematurely marked this as to review. Sorry for that!

[danskmt]

No worries! Let me know when you want me to review it again.

[PeterSchafer]

Done!

[snyk-pr-review-bot]

PR Reviewer Guide 🔍

🧪 PR contains tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Lifecycle Logic Error 🟠 [major] The tearDown function derives the exit code based on the err parameter. In MainWithErrorCode, the sync.Once closure captures the err variable, which is initialized to nil and only updated once rootCommand.Execute() returns. If an interrupt signal triggers tearDown while the command is still running (the intended use case for this refactor), tearDown will receive the current nil value of err. This results in the CLI returning exit code 0 and reporting success to analytics even when the process was terminated prematurely by a signal. finalExitCode = tearDown(err, errorListCopy, startTime, ua, cliAnalytics, networkAccess) Context Inconsistency 🟡 [minor] The tearDown function creates a new teardownCtx with a 5-second timeout to ensure cleanup operations don't hang. However, it passes globalContext to displayError instead of teardownCtx. If globalContext is already cancelled (e.g., if it was hooked to a termination signal) or if the UI output blocks, displayError may fail to show the final error message or may bypass the teardown grace period. Using teardownCtx would ensure the error display is subject to the same lifecycle constraints as the rest of the teardown. displayError(outputError, globalEngine.GetUserInterface(), globalConfiguration, globalContext)

📚 Repository Context Analyzed This review considered 23 relevant code sections from 12 files (average relevance: 0.92) cliv2/cmd/cliv2/main.go (3 segments, lines 1-203) cliv2/cmd/cliv2/logheaderfooter.go (lines 1-254) cliv2/cmd/cliv2/exitcode.go (lines 1-197) cliv2/cmd/cliv2/debug.go (lines 1-73) cliv2/cmd/cliv2/errorhandling.go (lines 1-104) cliv2/pkg/basic_workflows/globalresources.go (lines 1-128) scripts/upgrade-snyk-go-dependencies.go (lines 1-135) ... and 5 more file(s)