Skip to content

fix: correct RedisQueue disposal ordering to prevent ObjectDisposedException during shutdown#166

Open
niemyjski wants to merge 1 commit into
mainfrom
fix/dispose-cts-ordering
Open

fix: correct RedisQueue disposal ordering to prevent ObjectDisposedException during shutdown#166
niemyjski wants to merge 1 commit into
mainfrom
fix/dispose-cts-ordering

Conversation

@niemyjski
Copy link
Copy Markdown
Member

Summary

  • Reorders RedisQueue.Dispose() to call SignalDispose() first, wait for workers and maintenance task, then base.Dispose() last
  • Adds Dispose_WithMaintenanceRunning_DoesNotThrowObjectDisposedException test wiring

Root Cause

RedisQueue.Dispose() called base.Dispose() first which destroyed the CancellationTokenSource before the maintenance task was waited on. The still-running DoMaintenanceWorkLoopAsync then accessed DisposedCancellationToken (calling .Token on the disposed CTS), throwing ObjectDisposedException logged as a warning during Kubernetes graceful shutdown.

Dependencies

Requires FoundatioFx/Foundatio#519 (introduces SignalDispose() in MaintenanceBase)

Test plan

  • New test validates dispose does not throw with maintenance running
  • All existing queue tests pass

Fixes #165

…ception during shutdown

Reorder RedisQueue.Dispose() to signal cancellation first via SignalDispose(),
wait for workers and maintenance task to terminate, then call base.Dispose()
which disposes the CTS last. Previously base.Dispose() was called first which
destroyed the CTS while background tasks were still running.

Fixes #165
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.

Redis Queue Maintenance Job uses disposed CancellationTokenSource and Logs Errors

1 participant