HitsPerPage is not working , It causes infinitive api calls

Describe the bug 🐛 I downloaded https://github.com/algolia/instantsearch-ios-examples this repo. I am using algolia in my project and found lots of calls happens . and found out that Multi Index search has pagination issue . hitsPerPage is not working properly. I used flex to check network history for api calls. https://github.com/FLEXTool/FLEX.

To Reproduce 🔍 Steps to reproduce the behavior: I tried two cases here

hitsPerPage = 1, which cause infinitive api calls
1. Go to class MultiIndexDemoViewController.swift
2. On line number 122, have function called setup(). Added this line multiIndexHitsConnector.searcher.indexQueryStates[0].query.hitsPerPage = 1
```
func setup() {
**multiIndexHitsConnector.searcher.indexQueryStates[0].query.hitsPerPage = 1**
multiIndexHitsConnector.searcher.search()
addChild(hitsViewController)
hitsViewController.didMove(toParent: self)
}
```
changed offset of HitsInteractor from 10 to 40 and hitsPerPage to 10
1. Go to class MultiIndexDemoViewController.swift
2. Line number 93, have init function called and changed it as below

 let indexModules: [MultiIndexHitsConnector.IndexModule] = [
      .init(indexName: MultiIndexDemoSection.movies.indexName, hitsInteractor: HitsInteractor<Movie>(infiniteScrolling: .on(withOffset: **40**), showItemsOnEmptyQuery: true)),
      .init(indexName: MultiIndexDemoSection.actors.indexName, hitsInteractor: HitsInteractor<Hit<Actor>>(infiniteScrolling: .on(withOffset: 10), showItemsOnEmptyQuery: true)),
    ]

 func setup() {
    **multiIndexHitsConnector.searcher.indexQueryStates[0].query.hitsPerPage = 10**
    multiIndexHitsConnector.searcher.search()
    addChild(hitsViewController)
    hitsViewController.didMove(toParent: self)
  }

Expected behavior 💭 Found that It reaches to infinite api calles , I checked in flex which has more than 12000+ api calls . If I scroll the collection view in demo InstantSearch -> Paging(Section) -> Paging Multiple Index. It would have crash too

It should not have crash and also hitsPerPage should have one api call until scroll happens again
Pagination should work accurately

Screenshots 🖥 Simulator Screen Shot - iPhone 12 Pro Max - 2021-10-27 at 16 54 56

https://drive.google.com/file/d/1eMKJ46lVlm4DisonZWp2gxMBS0ioOb1I/view?usp=sharing

Environment:

OS: iOS 14.2

Additional context Let me know if you need more help here

Hi @vishalgspaceo,

I carefully examined the issue reproduction steps you provided. Actually this behaviour caused by an intended memory optimization. To avoid running out of device memory during the aggressive hits scrolling, the pagination engine keeps in memory 3 pages of hits before the first visible result and 3 pages of hits after last visible result. The value 3 is a hardcoded empirically derived value.

Let's examine the cases you reported one by one. First of all, these issues are not related to multi-index search. You can reproduce them in the single index search experience as well by setting the same parameters values.

Given:

Search result screen presenting 3 result hits at once (the case of multi-index demo).

1. First case

Query.hitsPerPage = 1 means that 1 page of results is equivalent of 1 hit HitsInteractor(infiniteScrolling(.on(withOffset: 10))) means that the pagination engine might ensure the presence of 10 hits before the first visible hit and 10 hits after the latest visible hit and trigger the corresponding network request if needed. pageCleanUpOffset = 3 means that the pagination engine when the page with index n is loaded, removes the pages with indices less than n-3 and more than n+3.

The multi-index search example presents 3 hits on the screen at once with indices 0, 1, 2.
Three search requests will be instantly performed to ensure their appearance.
The first presented hit has index 0, so the pagination engine doesn't request the 10 preceding hits.
The latest presented hit has index 2, so the pagination engine might ensure the presence of hits at indices 3...12.
Since the hitsPerPage parameter is set to 1, it will perform 10 more network requests to fetch pages/hits at indices 3...12 (by the way, each of them counts as a separate search operation).
The problems start when you get the hit/page with index 4. Since pageCleanUpOffset is equal to 3, the pagination engine will purge the pages with indices less than 4-3 = 1 and 4+3 = 7. As result, the page/hit 0 will be purged. But the hit 0 is visible right now, so it will be requested again.
When the page/hit 0 is fetched, the pagination engine will purge the pages with indices greater than 0 + 3 = 3, so the page/hit 4 will be purged. Here we have an infinite loop due to concurrency between the infinite scrolling offset value and the page clean-up offset due to small hitsPerPage value.

2. Second case

Query.hitsPerPage = 10 HitsInteractor.infiniteScrolling(.on(withOffset: 40) pageCleanUpOffset = 3

When the latest visible hit at index 2 appears it asks the pagination engine to ensure the presence of hits with indices 3...42.
The hits 0...9 are already fetched during the initial search request, so the hits to request have indices 10...42.
Since hitsPerPage is set to 10, it will require 4 additional network requests to fetch 4 pages of 10 hits (10+10+10+ one more page of 10 from which the pagination engine only requires first 3 hits).
And once again, when the 4th page is fetched and since pageCleanUpOffset = 3, the pagination engine will purge the pages with indices less than 4 - 3 = 1 and 4 + 3 = 7. So the first page with index 0 will be removed. But this is the first page which appears on the screen right now, so the pagination engine will request page at index 0 again and once it's fetched, will cleanup the page 4. One more inifinite loop.

Conclusion

Since from the InstantSearch side we cannot control or predict the number of visible hits due to different rows/cell sizes or even dynamic autolayout sizing, we decided to keep the pagination parameters configurable. The default configuration:

20 hits per page
5 hits required before the first visible hit and after the last visible hit

is reasonable for most mobile search experiences to ensure a decent performance. You can fine tune these parameters to ensure the best performance in your application. The fact that they are exposed doesn't mean that everything might work flawlessly with any set of values of these parameters. Briefly:

It's not a good idea to set the hitsPerPage value less than the number of hits appearing on the screen. You might want to present at least one page of hits on you screen at once.
It's not a good idea to set the infinite scrolling offset value greater than hitsPerPage value. The reason of this parameter is to request 1 more page before/after the visible area to ensure the smooth infinite scrolling.

We expect that if a developer alters the default values of these parameters, he knows what he is doing.

The only problem I see here is the private and hardcoded pageCleanUpOffset parameter and the missing warning in the documentation to be careful with pagination parameters 🙂

If you have a concrete infinite scrolling/pagination issue with your implementation where such specific pagination parameters make sense, I would be glad to discuss it and to find an optimal solution.

algolia / instantsearch-ios