[client] Add stack trace for bundle

[pappz]

Describe your changes

Issue ticket number and link

Stack

Checklist

• Is it a bug fix
• Is a typo/documentation fix
• Is a feature enhancement
• It is a refactor
• Created tests that fail without the change (if possible)

By submitting this pull request, you confirm that you have read and agree to the terms of the Contributor License Agreement.

Documentation

Select exactly one:

• I added/updated documentation for this change
• Documentation is not needed for this change (explain why)

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

• New Features

  • Stack trace data is now captured and included in debug bundles for enhanced diagnostics.

• Documentation

  • Updated documentation to describe the new stack trace file and its contents within debug bundles.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

A new stack trace capture feature was added to the debug bundle generator. The implementation includes a new addStackTrace() method that captures goroutine stack traces into a 5 MB buffer and writes them as stack_trace.txt to the ZIP archive, integrated into the bundle creation workflow with non-fatal error handling.

Changes

Cohort / File(s)	Summary
Stack Trace Capture Feature client/internal/debug/debug.go	Added addStackTrace() method to capture current goroutine stack traces into a buffer and write to ZIP archive; integrated into createArchive() workflow after profiling; updated readme with "Stack Trace" section describing file contents and listing in bundle contents

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Verify the 5 MB buffer size is appropriate for typical stack trace output
• Confirm error handling is correct (logged failures do not interrupt bundle creation)
• Check integration point in createArchive() is in the correct sequence
• Validate readme updates accurately describe the stack trace file contents and purpose

Poem

🐰 Hop hop, a trace so bright,
Stack frames captured in the night,
Five megs of goroutines revealed,
Debug secrets now unsealed! ✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description is largely incomplete; it consists almost entirely of empty template sections with no actual content about the changes, rationale, or implementation details provided.	Fill in the 'Describe your changes' section with concrete details about the stack trace feature implementation, add the issue ticket link, explain why documentation is not needed, and remove the placeholder Docs PR URL.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main change: adding stack trace functionality to the debug bundle.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch debug-stack

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
1 Accepted issue

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

client/internal/debug/debug.go (1)

533-543: Consider detecting and warning about potential truncation.

The implementation correctly captures stack traces, but if the traces exceed the 5 MB buffer, they'll be silently truncated. This could result in incomplete debugging information.

Consider adding truncation detection:

 func (g *BundleGenerator) addStackTrace() error {
 	buf := make([]byte, 5242880) // 5 MB buffer
 	n := runtime.Stack(buf, true)
+	
+	if n == len(buf) {
+		log.Warnf("stack trace may be truncated: captured %d bytes (buffer full)", n)
+	}

 	stackTrace := bytes.NewReader(buf[:n])
 	if err := g.addFileToZip(stackTrace, "stack_trace.txt"); err != nil {
 		return fmt.Errorf("add stack trace file to zip: %w", err)
 	}

 	return nil
 }

Additionally, consider extracting the magic number to a named constant for better maintainability:

+const stackTraceBufferSize = 5242880 // 5 MB buffer for stack traces
+
 func (g *BundleGenerator) addStackTrace() error {
-	buf := make([]byte, 5242880) // 5 MB buffer
+	buf := make([]byte, stackTraceBufferSize)
 	n := runtime.Stack(buf, true)

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c29bb1a and 4ff1a53.

📒 Files selected for processing (1)

• client/internal/debug/debug.go (4 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

client/internal/debug/debug.go (1)

shared/management/status/error.go (1)

• Errorf (70-75)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (13)

• GitHub Check: Build Cache
• GitHub Check: Client / Unit
• GitHub Check: Darwin
• GitHub Check: release_ui_darwin
• GitHub Check: release
• GitHub Check: Linux
• GitHub Check: Windows
• GitHub Check: release_ui
• GitHub Check: JS / Lint
• GitHub Check: Android / Build
• GitHub Check: Client / Unit
• GitHub Check: iOS / Build
• GitHub Check: Client / Unit

🔇 Additional comments (3)

client/internal/debug/debug.go (3)

59-59: LGTM!

The documentation accurately describes the stack trace file and is appropriately placed alongside other profiling artifacts.

---

113-115: LGTM!

The Stack Trace section provides clear documentation about the new file's purpose and contents.

---

334-336: LGTM!

The error handling is consistent with other optional bundle components, appropriately logging failures without aborting the entire bundle creation.