Skip to content
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

Remove two types of nacks - "Nonexistent client" & "Readonly client" #7753

Merged
merged 9 commits into from
Oct 9, 2021

Conversation

vladsud
Copy link
Contributor

@vladsud vladsud commented Oct 6, 2021

This is part of looking into #7137 (nacks, specifically - tight nack loops).
This change adds logic for DeltaManager to realize when it does not have "write" connection and stop sending ops on such connections. This removes "expected" nacks from the workflow. Remaining nack types are (in most cases) logical errors that needs to be raised in telemetry and looked into (10K unsummarized ops, 1Mb+ ops, etc.).
Removing "expected" nacks from the workflows allows us to make next step - apply some kind of workflow that breaks tight infinite loop of remaining nacks types. For example, we may add delays, or better - close container if we see number of nacks in a row (this is not part of this change, I'll continue to use this issue to track this work).

The con of this approach - it adds more logic to already complicated DeltaManager.

One of the other pros - it makes things more consistent to other layers. I.e. if Container checks for connection mode and it's "write", it knows for sure that it can send an op. Even more important - client knows that it should not send ops (for example, consensus / leader election DDSs would stop sending ops, and allow this client to stay in "read" connection mode once it got there).

(cherry picked from commit 719c03f131d025cd8f74db74e1a716dedab69911)
@github-actions github-actions bot added the area: loader Loader related issues label Oct 6, 2021
vladsud added a commit that referenced this pull request Oct 8, 2021
…DDS tests (#7784)

Slight changes in reconnect logic (see PRs #7753, #7393) result in failures in PropertyDDS UTs.

Looking a bit deeper, I can't easily follow intentions in OpProcessingController.
For example, OpProcessingController.process(dm1) will leave all but dm1 paused. UTs do rely on that (it's pretty clearly from some of them), in other places it feels like it's unintended result. And I do not think it correctly waits for all pending activity to be flushed (as observed in above mentioned PRs).

Given that it's deprecated and repo uses LoaderContainerTracker (explicitly or implicitly through), it's time to do the move.

Some random tests fail with this change, but are addressed by increasing timeout.
We saw this problem before with these tests - see pending #7350
@github-actions github-actions bot added the area: tests Tests to add, test infrastructure improvements, etc label Oct 9, 2021
@msfluid-bot
Copy link
Collaborator

msfluid-bot commented Oct 9, 2021

@fluidframework/base-host: +1.21 KB
Metric NameBaseline SizeCompare SizeSize Diff
main.js 188.02 KB 189.23 KB +1.21 KB
Total Size 215.61 KB 216.82 KB +1.21 KB
@fluid-example/bundle-size-tests: No change
Metric NameBaseline SizeCompare SizeSize Diff
container.js 163.43 KB 163.43 KB No change
map.js 44.71 KB 44.71 KB No change
matrix.js 143.36 KB 143.36 KB No change
odspDriver.js 180.97 KB 180.97 KB No change
odspPrefetchSnapshot.js 39.1 KB 39.1 KB No change
sharedString.js 164.93 KB 164.93 KB No change
Total Size 769.18 KB 769.18 KB No change

Baseline commit: 5fc2cbf

Generated by 🚫 dangerJS against 87b480a

vladsud added a commit that referenced this pull request Dec 7, 2021
Closes issue #8398 
Partial undo of PR #7753
Follow up / potential next steps - issue #8483
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: loader Loader related issues area: tests Tests to add, test infrastructure improvements, etc
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants