Skip to content

fix: recover panics in the fetchUserTokens worker goroutine#105

Open
robert-chiniquy wants to merge 1 commit into
mainfrom
rch/bugfix/goroutine-recover
Open

fix: recover panics in the fetchUserTokens worker goroutine#105
robert-chiniquy wants to merge 1 commit into
mainfrom
rch/bugfix/goroutine-recover

Conversation

@robert-chiniquy
Copy link
Copy Markdown
Contributor

`fetchUserTokens` spawns a bounded worker pool that fans out one goroutine per user, each calling `client.ListTokens` and downstream Google SDK code. None of the workers had a `defer recover()`, so a panic in any user's token-fetch path crashed the entire connector process rather than just failing that user's sync.

Added a `defer recover()` at the top of the worker that logs the panic + stack via the existing zap logger and lets the goroutine exit; the user's slot in `results` stays at its zero value (`userAppsResult{}`) so the outer loop treats the user as having no enumerable apps. The semaphore `Release` + `wg.Done` defers fire normally so the pool unwinds cleanly.

How found: occult-go-analysis baton pool scan (2026-05-20), detector `goroutine_without_recover`.

fetchUserTokens spawns a bounded worker pool that fans out one
goroutine per user, each calling client.ListTokens and downstream
Google SDK code. None of the workers had a defer recover(), so a
panic in any user's token-fetch path crashed the entire connector
process rather than just failing that user's sync.

Added a defer recover() at the top of the worker that logs the
panic + stack via the existing zap logger and lets the goroutine
exit; the user's slot in results stays at its zero value
(userAppsResult{}) so the outer loop treats the user as having
no enumerable apps. The semaphore Release + wg.Done defers fire
normally so the pool unwinds cleanly.

How found: occult-go-analysis baton pool scan (2026-05-20),
detector goroutine_without_recover.
@robert-chiniquy robert-chiniquy requested a review from arreyder May 20, 2026 18:53
@github-actions
Copy link
Copy Markdown
Contributor

Connector PR Review: fix: recover panics in the fetchUserTokens worker goroutine

Blocking Issues: 0 | Suggestions: 0 | Threads Resolved: 0
Review mode: full
View review run

Review Summary

This PR adds a defer recover() at the top of the worker goroutine in fetchUserTokens so that a panic in any user's token-fetch path is logged (with user ID, panic value, and stack trace) instead of crashing the entire connector process. The defer ordering is correct (recover runs first in LIFO, then semaphore release, then WaitGroup done), the goroutine's zero-value result slot causes the outer loop to treat a panicking user as having no enumerable apps, and no sensitive data is exposed in the log output. No issues found.

Security Issues

None found.

Correctness Issues

None found.

Suggestions

None.

Copy link
Copy Markdown
Contributor

@github-actions github-actions Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No blocking issues found.

@robert-chiniquy robert-chiniquy marked this pull request as ready for review May 20, 2026 21:03
@robert-chiniquy robert-chiniquy requested a review from a team May 20, 2026 21:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants