You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This ticket is only about the incremental event catch-up channel — the delta feed that says "something changed, update your view." It is not about how a project's content is loaded. Those are two separate, independently-persisted things:
The project itself — persisted durably on the server as an append-only change history and materialized into the current in-memory ontology when opened. This is how everyone (owner or collaborator) gets the actual content on screen, via direct state queries (hierarchy, frames, …). This ticket does not touch that path.
The event archive — a separate log (event-history service) used only for the incremental delta channel. This is what the bug below is about.
Because current state already comes from the durable project, the event channel does not need to replay history to reconstruct anything — it only needs to deliver changes that happen from the moment you're connected onward.
Problem (plain language)
The client's event bookmark resets to "the very beginning" (position 0) on every page load, so the first catch-up fetch asks the event archive for every event it has ever recorded for this project and re-processes all of it. The archive is never purged, so this grows without bound.
This happens on any open, not just when a collaborator joins during active editing — the project owner opening a completely quiet project triggers it too, because the bookmark always starts at 0.
Two costs:
Wasteful and redundant: the client already has current state from the durable project load, so re-streaming the entire delta history to arrive at the same place is pure overhead — a large download plus a burst of event-bus firings at open.
Correctness risk: re-applying old deltas on top of already-current state is the same failure family as the stale-replay / resurrection bug in Add gap detection so the client can tell when it missed events #297 (re-adding a removed parent, un-deleting a class). Starting at zero maximizes exposure to it.
Suggested solution
Start the client's position at the current head when a project opens, rather than at the beginning of history. The initial view already fetches current state through other calls, so the event stream only needs to cover changes from the open onward (plus the small recent window needed to bridge the load). Provide a way to fetch "the latest position" so the client can begin near the head instead of at zero.
Depends on #296 — there must be a single, coherent "current position" for the client to anchor to (today the push path and the archive don't share one).
Done when
Opening a project does not download or re-process the project's full event history.
Open time and event volume on a project with a long history are comparable to one with a short history.
Live updates from the moment of opening still arrive correctly (no gap introduced by starting near the head).
Part of #294.
Repo(s):
webprotege-gwt-ui,webprotege-event-history-serviceScope note (read first)
This ticket is only about the incremental event catch-up channel — the delta feed that says "something changed, update your view." It is not about how a project's content is loaded. Those are two separate, independently-persisted things:
Because current state already comes from the durable project, the event channel does not need to replay history to reconstruct anything — it only needs to deliver changes that happen from the moment you're connected onward.
Problem (plain language)
The client's event bookmark resets to "the very beginning" (position 0) on every page load, so the first catch-up fetch asks the event archive for every event it has ever recorded for this project and re-processes all of it. The archive is never purged, so this grows without bound.
This happens on any open, not just when a collaborator joins during active editing — the project owner opening a completely quiet project triggers it too, because the bookmark always starts at 0.
Two costs:
Suggested solution
Start the client's position at the current head when a project opens, rather than at the beginning of history. The initial view already fetches current state through other calls, so the event stream only needs to cover changes from the open onward (plus the small recent window needed to bridge the load). Provide a way to fetch "the latest position" so the client can begin near the head instead of at zero.
Depends on #296 — there must be a single, coherent "current position" for the client to anchor to (today the push path and the archive don't share one).
Done when