Repository navigation
fix(ui): start the event stream of a screen after its read - #190
Merged
Merged
Conversation
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.
What changes
A screen that opened used to start the event stream from the start of the
cluster's event buffer. The buffer sent again every change it held, and the
screen read its list once more for each of them: a list was read two or three
times when it opened. Now each read notes the index it read at, and the stream
starts after it. A change the screen already shows does not read it again.
context (
nomad.WithReads,NoteRead), so no signature ininternal/nomadchanges.
Eventstakes the index to start from, and each change carries itsindex.
answer, from the lowest of them plus one, and drops a change at or below
the index of its topic.
screen read again: a change dropped against the newer index is not lost.
a limit its allocation index is
EveryIndex, and a change dropped in thattime is kept. When a client gets a limit, the screen reads again if the
kept change is newer than the new read.
services is the newest service on the page, which made the list read twice
when it opened.
that failed after its list answered, and a queue with a pool that did not
answer.
pace.
they open.
Left for later: a screen of one object (a job, a client) still reads again
when something else it follows changed after that object did. #189 tracks it.
Closes #165
Checklist
make checkis greenfeat(ui): ...,fix(nomad): ...