-
Notifications
You must be signed in to change notification settings - Fork 536
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
Integrate OpProcessingController functionality into LoaderContainerTracker #5635
Conversation
} | ||
|
||
const minSeqNum = containersToApply[0].deltaManager.minimumSequenceNumber; |
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.
it's a bit weird we need to special case the quorum, won't other consensus structures have the same issue? i'd rather make the test wait for the side effect it cares about, approve or reject in this case
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.
All the consensus data structure only need the round trip. The quorum proposal is unique in that it allow other client to reject, thus needs to wait until minSeqNumber to catch up.
It is debatable that whether we should have the test wait for proposal accepted or not and just let op resume in the mean time. But I do see a benefit to basically ensure the system has completely "settled".
Fully replace usage of
OpProcessingController
withLoaderContainerTracker
addDeltaManager
OpProcessingController
manually track op outbound and inbound to keep track of inflight ops.LoaderContainerTracker
do less tracking, instead it use the follow condition to tell if the containers are in syncisDirty
containersclientId
in quorum of any container that is not tracked and still opened.minSeqNum >= lastProposalSeqNum
) [New inLoaderContainerTracker
]lastSequenceNumber
of all container is the sameclientSequenceNumberObserved
is the same asclientSequenceNumber
sent!isDirty
, but include task scheduler ops thatisDirty
doesn't coverNoOp
is tracked and don't count as pending ops. See Issue Reconsider noop coalescing #5629This fixes
pendingOps.spec.ts
test where there is a bad interaction betweenOpProcessingController
andLoaderContainerTracker
whereOpProcessingController
paused theDeltaManager
whileLoaderContainerTracker
is waiting.OpProcessingController
is mark as deprecated and will be remove on the next release to allow a grace period for migrationAlso:
fluid:test-utils:ops
orfluid:test-utils:wait
)leader.spec.ts
, as those condition would not be true .TestObjectProvider
to get automatic tracking