Skip to content

Replace PaginatedMessages with HistoryPage#25

Open
zknill wants to merge 1 commit intomainfrom
zak/paginated-history
Open

Replace PaginatedMessages with HistoryPage#25
zknill wants to merge 1 commit intomainfrom
zak/paginated-history

Conversation

@zknill
Copy link
Copy Markdown
Contributor

@zknill zknill commented Apr 2, 2026

The PaginatedMessages interface used parallel arrays (items, itemHeaders, itemSerials, rawMessages) matched by index — fragile and wider than its sole internal consumer (View) needs. Since the type is no longer part of the public API, consolidate into HistoryItem (message + headers + serial per item) and HistoryPage.

Also guard View.loadOlder() against concurrent calls — a second call while the first is still awaiting now silently no-ops instead of corrupting shared pagination state.

AIT-670, AIT-671

@zknill zknill requested a review from owenpearson April 2, 2026 11:08
The PaginatedMessages interface used parallel arrays (items,
itemHeaders, itemSerials, rawMessages) matched by index — fragile
and wider than its sole internal consumer (View) needs. Since the
type is no longer part of the public API, consolidate into
HistoryItem (message + headers + serial per item) and HistoryPage.

Also guard View.loadOlder() against concurrent calls — a second
call while the first is still awaiting now silently no-ops instead
of corrupting shared pagination state.

AIT-670, AIT-671
@zknill zknill force-pushed the zak/paginated-history branch from 7cdaaa5 to ff9a4bc Compare April 10, 2026 09:33
Copy link
Copy Markdown
Member

@owenpearson owenpearson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks good, one question:

@@ -197,8 +197,8 @@ export class DefaultView<TEvent, TMessage> implements View<TEvent, TMessage> {

async loadOlder(limit = 100): Promise<void> {
if (this._closed || this._loadingOlder) return;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be outside of the scope of this PR, but this looks weird to me: if you call loadOlder twice the second promise returned will resolve immediately even though the first promise is still busy loading older messages. Would it be better to reject the promise in this case?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not really an error though so I don't think reject is a good idea, it's just to stop concurrent calls to loadOlder. When the first one resolves the data will be available.

IMO it's not really a problem, but if we think it is, then I'd say we return a promise that resolves when the inflight call to loadOlder resolves.

@zknill zknill requested review from a team and mschristensen and removed request for a team April 13, 2026 08:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants