Skip to content
Cockpit0.29.0
A snapshot: read at commit 707a04c7ce8 on 2026-10-18T00:06:01Z by majordomus 0.29.0. Nothing on this page is read again. See it live

I2679

The Observatory follows a stream with a cursor instead of asking for its page again

Where it stands

devtask.issue
Readiness
complete completion is recorded and every required evidence token is present
Status
DONE
Can start
not now
Milestone
Milestone status
ACTIVE
Wave
0
Waiting on
none
Holds back
none
Behind it in all
0
Evidence
1 of 1
A move writes the repository: it stamps one field of this issue's record and appends one event to the ledger, and a commit will carry both.
The same moves from a terminal

majordomus plan start I2679

majordomus plan verify I2679

majordomus plan done I2679

What it is

Objective
Make a change on the mesh reach the display when it happens, and make a gap in what was received something the display knows and says.
Why
The Observatory learns of a change by asking for its own page every 15 seconds. That is honest and coarse: an event is seen up to 15 seconds late, events between two readings are seen only as a difference, and a missed reading is indistinguishable from a quiet mesh. The owner's specification asks for reconnect, deduplication, cursor recovery and bounded queues.
Now
share/ui/observatory.js polls its page with ?fragment every 15 seconds and backs off to 120. The server already keeps a live-event stream for executions with a cursor per execution, and the mesh journal is ordered by stream and sequence.
Wanted
The display follows the server's existing event stream from a cursor, resumes from it after a disconnect, takes a fresh projection when the cursor has expired and says that it did, drops a duplicate by its identity, and holds a bounded number of events. No new transport is introduced.
Done when
unknown: the record declares no `completion`
Risk
unknown: the record declares no `risk`

Acceptance

  • An event appended to the mesh journal reaches the display without a reading of the whole page, and a case proves it through a real server
  • After a disconnect the display resumes from its cursor; with an expired cursor it takes a fresh projection and its status word says so
  • The same event delivered twice draws one mark, and the number of events the script holds has a declared bound
Validation
bin/majordomus plan validatebash test/run.sh 3011_the_observatory_draws_nothing_it_did_not_read
Evidence required
observatory_stream_resume_case
Evidence present
observatory_stream_resume_case

Scope

Touches
apps/majordomus-cli/src/ui/observatory.rsshare/ui/observatory.jsdocs/MAJORDOMUS_UI.md.ai/repo/project/issues/I2679.yaml
Not
A new stream protocol, event store or message brokerThe public snapshot, which reads nothing again
Depends on
none
Priority
p2
Profile
implementation
Parallel safe
true
Owner
unknown: the record declares no `owner`

The work so far

Branches
none
Merged
none
Commits
0
Trunk
master
Sessions
none
Created
2026-10-14
Updated
2026-10-14T12:31:39Z
Started
2026-10-14T12:31:19Z
Verified
unknown: the record declares no `verified_at`
Completed
2026-10-14T12:31:39Z

Synchronisation

Adapter
scripts/github-sync
Repository
unknown: the derived plan's header carries no repository
External issue
unknown: a live GitHub state; this executable makes no network call, so only `scripts/github-sync --check` can answer it
State there
unknown: a live GitHub state; this executable makes no network call, so only `scripts/github-sync --check` can answer it

Findings

Nothing is wrong with these records.