Skip to content

fix(ui): start the event stream of a screen after its read - #190

Merged
ingvarch merged 6 commits into
mainfrom
fix/stream-after-read
Nov 4, 2026
Merged

ingvarch merged 6 commits into
mainfrom
fix/stream-after-read

Conversation

@ingvarch

@ingvarch ingvarch commented Nov 4, 2026

Copy link
Copy Markdown
Owner

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.

  • Every read notes the index of each topic it read through its request
    context (nomad.WithReads, NoteRead), so no signature in internal/nomad
    changes. Events takes the index to start from, and each change carries its
    index.
  • A screen keeps one read index per topic. It opens its stream on its first
    answer, from the lowest of them plus one, and drops a change at or below
    the index of its topic.
  • An answer older than the page, which comes after a newer one, makes the
    screen read again: a change dropped against the newer index is not lost.
  • The client list reads allocations only when a client has a limit. Without
    a limit its allocation index is EveryIndex, and a change dropped in that
    time is kept. When a client gets a limit, the screen reads again if the
    kept change is newer than the new read.
  • The jobs list keeps the index of the list. The index of the counts of the
    services is the newest service on the page, which made the list read twice
    when it opened.
  • A read that failed notes no index. This includes a part of the overview
    that failed after its list answered, and a queue with a pool that did not
    answer.
  • Once the stream opens after the answer, the poll timer restarts at the slow
    pace.
  • docs/configuration.md says which screens can still read once more when
    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

  • The test for this change was written first and failed
  • make check is green
  • The title is a conventional commit: feat(ui): ..., fix(nomad): ...

@ingvarch ingvarch added this to the v0.17.0 milestone Nov 4, 2026
@ingvarch ingvarch added bug Something isn't working ui Screens, keys and the header nomad The client of the Nomad API and what it reads labels Nov 4, 2026
@ingvarch
ingvarch merged commit baaa3e7 into main Nov 4, 2026
5 checks passed
@ingvarch
ingvarch deleted the fix/stream-after-read branch November 4, 2026 15:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working nomad The client of the Nomad API and what it reads ui Screens, keys and the header

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Start the event stream after the read of the screen

1 participant