Skip to content

fix(dashboard): take the booker's name from the owner's read, not the event - #69

Merged
simonorzel26 merged 3 commits into
mainfrom
fix/dashboard-label-from-read
Oct 4, 2026
Merged

simonorzel26 merged 3 commits into
mainfrom
fix/dashboard-label-from-read

Conversation

@simonorzel26

@simonorzel26 simonorzel26 commented Oct 4, 2026 •

Copy link
Copy Markdown
Member

Companion to open-deltat/deltat#49 (merged), which stops change notifications carrying booking labels: a label is whatever the booker typed, often their name, and every subscriber on a calendar heard it. On delt.at that includes any browser watching a public booking page, through the demo's WebSocket bridge.

The owner dashboard (demo/components/dashboard/live-schedule.tsx) displayed the name straight from the BookingConfirmed event, so against a kernel with #49 a live booking would show no name until a reload.

Change

  • Names come from one place, the owner's read (getCalendar, the same owner-checked action the page loads with). A booking's name never changes, so every reply adds to a single name lookup that the day view, month view and activity log all read. A cancelled booking's log line keeps its name.
  • Events still show a change the moment it happens; the read then says which bookings exist. A read goes out at most 200 ms after the first change of a burst (it does not reset on every change, so steady traffic cannot starve it). Its booking list lands only if no change came in after it was sent, so a slow reply cannot undo what a later event showed; that change has already asked for the next read. Names from an overtaken reply still land.
  • Also reads on Lagged and whenever the stream (re)connects (mount, back from another tab, after a reconnect), since each means changes may have been missed. Before this, a tab switch brought back the page-load list and nothing corrected it.
  • A failed read, or one after the session expired, keeps what the events showed.

Works against kernels before and after #49 (the event's label is not used either way).

Checks

  • tsc --noEmit on the demo passes; bun test 469 pass, 0 fail.
  • Traced by hand: a single booking, two bookings with a read in flight, steady 150 ms traffic, a cancel overtaking a read.
  • Not exercised in a browser: the dashboard needs a real OIDC sign-in and there is no local bypass. To check after deploy: open a calendar's dashboard, book it from its public page in another window, and the name appears within a moment.

Left for later: a visible hint when reads keep failing (expired session), a per-principal rate limit on getCalendar now that the browser calls it, a narrower read than the whole calendar, and sharing the debounce with the hotel and stadium examples.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Vaz5XtKxcGVsLe9GeX186M

… event

deltat#49 stops change notifications carrying booking labels, since
anyone watching a calendar hears them. The owner dashboard showed the
name straight from the event, so a live booking would have appeared
nameless until a reload.

A confirmed booking now appears at once, then getCalendar (owner-checked)
fills in its name. The reply only fills names; which bookings exist
stays with the events, so two replies resolving out of order cannot
drop a newer booking. Works against kernels before and after deltat#49.

Claude-Session: https://claude.ai/code/session_01Vaz5XtKxcGVsLe9GeX186M
…ir names

Review of #69: copying only names from a read that returns the true
booking list threw the rest away, the promise had no catch, and the log
lost the name for good.

Events still show a change at once (with the event's label on kernels
before deltat#49). Each booking change then asks for one debounced
getCalendar; a reply lands only if no newer change came in after it was
asked for, so a slow reply cannot undo a later event. A failed or
signed-out read keeps what the events showed. The log stores the
booking id and looks the name up when it renders.

Claude-Session: https://claude.ai/code/session_01Vaz5XtKxcGVsLe9GeX186M
…t starve

Second review of #69. A booking's name never changes, so every read
adds to one name lookup that the timeline, the month view and the log
all use; a cancelled booking's log line keeps its name, and names land
even when a newer change overtakes the read's booking list.

A read now goes out at most 200 ms after the first change of a burst
instead of resetting on every change, so steady traffic cannot starve
it. Lagged and (re)connecting also read, since both mean changes may
have been missed. Leaving a calendar discards a reply still in flight.

Claude-Session: https://claude.ai/code/session_01Vaz5XtKxcGVsLe9GeX186M
@simonorzel26
simonorzel26 merged commit a339999 into main Oct 4, 2026
4 checks passed
@simonorzel26
simonorzel26 deleted the fix/dashboard-label-from-read branch October 4, 2026 17:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant