[PM-43815] feat: Make the dead letter sweep interval configurable

[withinfocus]

🎟️ Tracking

https://bitwarden.atlassian.net/browse/PM-43815. Configuration follow-up to the dead letter retention work.

📔 Objective

DeadLetterCleanupHostedService swept the integration dead letter sub-queues on a hard-coded one-hour interval, so changing the cadence meant changing code. The interval now comes from AzureServiceBus.DeadLetterSweepInterval, which sits next to the DeadLetterRetention setting that turns the sweep on at all. The default is the same hour it always was, so a deployment that leaves the setting alone sees no change.

The service resolves the interval once at startup and checks it against the range Task.Delay accepts. Zero or a negative value would leave no pause between sweeps. A value past the roughly 49 days Task.Delay takes would throw and stop the events processor, and it would do that after the first sweep had already run, so the failure looks like a delayed crash rather than a bad startup. That upper bound is easy to cross by accident: configuration parses a bare number as days, so 720 entered for 720 hours becomes 720 days. Both cases log a warning and fall back to the default interval.

Tests cover a configured value, the boundary, and each out-of-range case. One of them pins the maximum against what Task.Delay actually accepts, so the constant cannot drift from the framework limit.

[github-actions]

🤖 Bitwarden Claude Code Review

Overall Assessment: APPROVE

This change replaces the hard-coded one-hour sweep cadence in DeadLetterCleanupHostedService with GlobalSettings.EventLogging.AzureServiceBus.DeadLetterSweepInterval, defaulting to the same hour so existing deployments are unaffected. The interval is resolved once at startup and range-checked before it reaches Task.Delay; out-of-range values log a warning and fall back to the default rather than throwing after a sweep has already run. MaxSweepInterval is uint.MaxValue - 1 milliseconds, which matches the Timer.MaxSupportedTimeout bound both Task.Delay overloads validate against, and the events processor resolves TimeProvider to TimeProvider.System through TryAddSingleton, so that bound applies to the real delay path. Tests cover a configured value, the boundary, both out-of-range directions, and the days-vs-hours configuration binding pitfall, with one test pinning the constant against the framework limit so it cannot drift.

Code Review Details

No findings.

[codecov]

Codecov Report

❌ Patch coverage is 88.23529% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 64.63%. Comparing base (c6ac662) to head (82a3655).

Files with missing lines	Patch %	Lines
.../EventsProcessor/DeadLetterCleanupHostedService.cs	86.66%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##           main    #8401       +/-   ##
=========================================
+ Coverage      0   64.63%   +64.63%     
=========================================
  Files         0     2482     +2482     
  Lines         0   106388   +106388     
  Branches      0     9665     +9665     
=========================================
+ Hits          0    68765    +68765     
- Misses        0    35282    +35282     
- Partials      0     2341     +2341     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.