commit a0da72341b8159c5341af711e6b8991ef1aa7875
author Diego Zambelli Sessona <diego.sessona@gmail.com> Mon Jul 10 14:22:29 2023 +0100
committer Diego Zambelli Sessona <diego.sessona@gmail.com> Mon Jul 10 14:22:29 2023 +0100
tree ccaa2aacdbbb44153960809bd1ca8d6e68b5e71d
parent 3bc24131ee6f62c89509f318665073715457dc05

Add configuration to disable indexes pagination

Add NONE option to disable index backend pagination,
allowing the user deciding between performance
and data consistency.

This option needs to be honoured by the indexing backend
and this change introduces the correct implementation
for Lucene.
We should also create the corresponding change on the
elasticsearch libModule for throwing an IAE to highlight
that the backend doesn't support NONE pagination type.

API pagination is not affected by this change and is
always preserved.

When having pagination, we could encounter some problems
in the result set, when moving from one page to the
next of the index results:
* duplicated entries (when new changes are created)
* missing entries (when changes are removed or set to
  private)
* wrong entries status (when changes are switching
  their state during the page switching)

Having duplicates or missing results could have side effects,
depending on the use-case of the consumer of the data.

For example, since indexes are used to populate some LoadingCache
(SearchingChangeCache [1]), inconsistent results returned by
the indexing backend may cause the cache loading function
to fail or keep an inconsistent state which doesn't reflect
the underlying data.

For this case, a workaround [2] has been put in place in master
and 3.8, however, it will not work for the missing
or inconsistent entries.

[1]: https://gerrit.googlesource.com/gerrit/+/refs/heads/stable-3.6/java/com/google/gerrit/server/git/SearchingChangeCacheImpl.java#157
[2]: https://gerrit-review.googlesource.com/c/gerrit/+/349995

Bug: Issue 287484350
Release-Notes: Introduce NONE pagination type and its support in Lucene indexing backend
Change-Id: I40f87895d9dac951ae30c5562b2ddbf28b34a41a
Co-Authored-With: Fabio Ponciroli <ponch78@gmail.com>