Skip to content

Conversation

@kacpersaw
Copy link
Contributor

@kacpersaw kacpersaw commented Feb 4, 2026

Summary

Tests were reviewed and are reasonable overall. This PR adds missing test coverage and fixes bugs found during review.

Changes

  • Bug Fix: Close() was not idempotent - calling it twice would panic due to closing already-closed channels. Added sync.Once to make it safe.
  • Bug Fix: Retry timers weren't cleaned up when context was canceled, causing integration tests to hang. Added cleanup() method to stop all retry timers when work loop exits.
  • New Tests:
    • TestCloseIdempotent: Verifies double-close doesn't panic
    • TestCloseDuringProcessing: Verifies close during active processing works correctly

Test Coverage Review

Well-Covered Areas ✓

  • tokenCache operations
  • logCache operations
  • logQueuer log queuing logic
  • Pod/ReplicaSet event handling
  • Secret reference resolution (EnvVar with SecretKeyRef)
  • Multi-namespace support
  • Label selector filtering

Remaining Minor Gaps (not addressed in this PR)

  • ConfigMapKeyRef is not implemented in the code, so no test needed
  • WaitForCacheSync only tested indirectly (acceptable)
  • Network failure/reconnection scenarios (complex to test)

- Add sync.Once to podEventLogger to ensure Close() is safe to call multiple times
- Add TestCloseIdempotent to verify double-close doesn't panic
- Add TestCloseDuringProcessing to verify close during active processing
@kacpersaw kacpersaw marked this pull request as ready for review February 5, 2026 09:14
Stop all active retry timers in logQueuer.cleanup() when the context
is canceled. This prevents retry timers from continuing to fire after
the podEventLogger is closed, which was causing integration tests to
hang waiting for httptest.Server to close.
p.closeOnce.Do(func() {
p.cancelFunc()
close(p.stopChan)
close(p.errChan)
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't you make this wait for the goroutines to exit too? by having a defer close(p.doneChan) at the top of the work() handler?

Address review feedback: Close() now waits for the work goroutine
to fully exit before returning. Added doneChan that is closed when
the work loop exits, and Close() blocks on receiving from it.

Also moved work goroutine startup to newPodEventLogger to ensure
it's only started once (not per-namespace).
func (l *logQueuer) work(ctx context.Context) {
func (l *logQueuer) work(ctx context.Context, done chan struct{}) {
defer l.cleanup()
defer close(done)
Copy link
Member

Choose a reason for hiding this comment

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

probs should be the first deffered handler no? defers run in LIFO order

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