refactor: remove PreExecCheck leaky abstraction and fix sync-over-async in ValkeyTransaction#359
Open
makubo-aws wants to merge 1 commit intovalkey-io:mainfrom
Conversation
ValkeyBatch.PreExecCheck() was a virtual hook that existed solely to support transaction preconditions. Batches have no concept of preconditions, so this was transaction-specific logic leaking into the base class. Additionally, ValkeyTransaction.PreExecCheck() called ExecuteImpl().GetAwaiter().GetResult() — the last remaining sync-over-async call in the codebase — which risks deadlocks in environments with a synchronization context (e.g. ASP.NET). Changes: - Remove virtual PreExecCheck() from ValkeyBatch and the if (PreExecCheck()) guard from ExecuteImpl(). ExecuteImpl() now unconditionally executes the batch, which is the correct behaviour for ValkeyBatch (conditions are a transaction concern only). - Move condition evaluation into ValkeyTransaction.ExecuteAsync() directly, using await instead of .GetAwaiter().GetResult(). - Short-circuit early (set _tcs result to null and return false) as soon as any condition fails, avoiding unnecessary work. - Rename the inner batch variable from b to conditionBatch for clarity. Fixes valkey-io#266
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #266
Problems
1. Leaky abstraction
ValkeyBatchdefined avirtual bool PreExecCheck()hook called fromExecuteImpl(). The base implementation was a no-op (return true), andValkeyTransactionoverrode it to evaluate preconditions before submitting theMULTI/EXECblock. Batches have no concept of preconditions — this was transaction-specific logic leaking into the base class.2. Sync-over-async
ValkeyTransaction.PreExecCheck()calledb.ExecuteImpl().GetAwaiter().GetResult()— the last remaining sync-over-async call in the codebase. This risks deadlocks in environments with a synchronization context (e.g. ASP.NET, UI frameworks).Changes
ValkeyBatch.csvirtual bool PreExecCheck()if (PreExecCheck()) { ... } else { _tcs.SetResult(null); }guard fromExecuteImpl().ExecuteImpl()now unconditionally executes the batch, which is correct — conditions are a transaction concern only.ValkeyTransaction.csprotected override bool PreExecCheck()ExecuteAsync()directly, usingawaitinstead of.GetAwaiter().GetResult()_tcsresult tonulland returnfalse) as soon as any condition fails, avoiding unnecessary workbtoconditionBatchfor clarity