-
Notifications
You must be signed in to change notification settings - Fork 973
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TransactionFrame Refactor #4307
Conversation
8a587fe
to
ac003d6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for dealing with this mess! I didn't have time to review everything, just mostly looked at the new interfaces.
709e745
to
8fdb81e
Compare
We also can keep the cache only used prior to protocol 8, right? |
I think that's what we do already? we're keeping it around to correctly apply the buggy behavior during replay, but we don't need this cache for normal in-sync operations. |
8fd5c80
to
22a0a2c
Compare
I've finished up another round of refactoring that hopefully should better divide the responsibilities of the TxFrames. Changes include:
There are three distinct responsibilities:
I think TransactionFrame is still doing too much, and ideally I'd like to break the responsibility from 3. into a new class (something like TransactionFrameApplicator). For a first pass though, I think making OperationFrames immutable and be owned by TransactionFrame gives us a much clearer distinction of responsibility than the first refactor. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks.
8c25df2
to
1d0fc8d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just a few questions. I haven't finished reviewing everything yet, but it's moving in the right direction!
Also, any thoughts on the test/rollout plan for this change? Given the blast radius of a bug in any of the Transaction/OperationFrame codepaths, I think in addition to full replay, we could utilize the fuzzer (I'm not certain what shape it's in though)
ba0d9f5
to
9480709
Compare
9480709
to
eed6cad
Compare
Description
Resolves #2163
This PR makes all
TransactionFrame
variants immutable. All mutable state, such asTransactionResult
and caches has been moved to theTransactionResultPayload
class. Hash caches are still inTransactionFrame
, but only because the contents they hash are immutable such that the cache can never be invalidated.To maintain our current testing framework,
TransactionTestFrame
acts as a wrapper class, combining an immutableTransactionFrame
with it's associatedTransactionResultPayload
object for easier testing.Checklist
clang-format
v8.0.0 (viamake format
or the Visual Studio extension)