PrimeNG Table lazy loading first index desynchronization when totalRecords changes mid-request

Pagination state consistency during concurrent data mutations

When using PrimeNG Table with [lazy]="true", the component relies on the first and rows parameters from LazyLoadEvent to request the correct page slice from the server. A race condition arises if the total record count changes between the moment the request is sent and the response arrives — for example, when another user deletes records or a background job archives data.

The totalRecords bound to the table may no longer match the server's actual count at response time. PrimeNG does not document how the internal first index should be reconciled when the returned dataset is smaller than expected or when the last page becomes empty. The component may retain a stale first value that points beyond the new last record, leaving the table blank until manual navigation occurs.

Applications that implement optimistic UI updates or operate in high-concurrency environments need a deterministic strategy for this scenario. The current behavior appears to depend on whether totalRecords is updated before or after the lazy load callback completes.

Open questions

• Does PrimeNG automatically clamp first to the new last page when totalRecords decreases during a pending lazy load?
• What is the recommended pattern for updating totalRecords atomically with the data array to avoid a flash of empty state?
• Should the server response include the authoritative totalRecords and first values for the client to adopt unconditionally?