Skip to content

Conversation

LukeButters
Copy link
Contributor

@LukeButters LukeButters commented Sep 18, 2025

Background

This is a simple change to reduce the amount of work we do. In most cases we will already have a Data Loss CT which means we can avoid creating multiple CTS and delayed tasks that will immediately throw.

Additionally the methods are updated such that we work on a consistent TaskCompletionSource since that value is replaced.

We are aiming to reduce as much work as possible in the normal case, to reduce queue overhead.

The AI wrote this:

  • Added TryGetTokenForDataLossDetection() method to IWatchForRedisLosingAllItsData interface
  • Implemented the method in WatchForRedisLosingAllItsData to return token immediately if monitoring is active
  • Updated RedisPendingRequestQueue to use try method first, falling back to GetTokenForDataLossDetection
  • Updated test implementations (RedisNeverLosesData and CancellableDataLossWatchForRedisLosingAllItsData)
  • Improves performance by avoiding CancellationTokenSource allocation when monitoring is already ready
  • Maintains backward compatibility with existing GetTokenForDataLossDetection method

How to review this PR

Quality ✔️

Pre-requisites

  • I have read How we use GitHub Issues for help deciding when and where it's appropriate to make an issue.
  • I have considered informing or consulting the right people, according to the ownership map.
  • I have considered appropriate testing for my change.

@LukeButters LukeButters requested a review from a team as a code owner September 18, 2025 01:00
…llationTokenSource creation

- Added TryGetTokenForDataLossDetection() method to IWatchForRedisLosingAllItsData interface
- Implemented the method in WatchForRedisLosingAllItsData to return token immediately if monitoring is active
- Updated RedisPendingRequestQueue to use try method first, falling back to GetTokenForDataLossDetection
- Refactored DequeueAsync to use centralized DataLossCancellationToken method instead of duplicating logic
- Updated test implementations (RedisNeverLosesData and CancellableDataLossWatchForRedisLosingAllItsData)
- Improves performance by avoiding CancellationTokenSource allocation when monitoring is already ready
- Maintains backward compatibility with existing GetTokenForDataLossDetection method
- Reduces code duplication by centralizing data loss cancellation token logic

Resolves TODO comment in WatchForRedisLosingAllItsData.cs
@LukeButters LukeButters force-pushed the feature/add-try-get-token-for-data-loss-detection branch from f412257 to df39b37 Compare September 18, 2025 01:25
Comment on lines +121 to +125
var token = watchForRedisLosingAllItsData.TryGetTokenForDataLossDetection();
if (token.HasValue)
{
return token.Value;
}
Copy link
Contributor Author

@LukeButters LukeButters Sep 18, 2025

Choose a reason for hiding this comment

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

This new code is about 10x faster than the below code.

The below code is almost always never executed.

Copy link
Contributor

@rhysparry rhysparry left a comment

Choose a reason for hiding this comment

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

✅ LGTM

Nits are very much non-blocking

return await localCopyOfTaskCompletionSource.Task.WaitAsync(cts.Token);
}


Copy link
Contributor

Choose a reason for hiding this comment

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

nit: extraneous blank line

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed


public CancellationToken? TryGetTokenForDataLossDetection()
{
if (TaskCompletionSource.Task.IsCompleted && TaskCompletionSource.Task.Status == TaskStatus.RanToCompletion)
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: Not sure how I missed this before, but is there a reason TaskCompletionSource is a public field? Should we keep that one private if nothing is relying on accessing it directly?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Wait it is private:
I guess I can remove the private and fall back to halibut defaults that make it private.

@LukeButters LukeButters enabled auto-merge (squash) September 18, 2025 02:18
@LukeButters LukeButters merged commit 0a58aa2 into main Sep 18, 2025
17 checks passed
@LukeButters LukeButters deleted the feature/add-try-get-token-for-data-loss-detection branch September 18, 2025 05:45
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