Clicking on the last page/record returns an error attached.

Mean while I present a psuedocode, I would like to give a hint - As and when the a!queryprocessAnalytics see the 10000+ index, it starts throwing an error. So the call to a!queryprocessAnalytics should be always shielded from sending an 10000+ index by opting for alternate approaches such as which we are discussing here. Simply speaking, as and when your pagingInfo is set to an index greater than 10000+, you should do as follows:
1. Fetch the whole dataset by calling a!queryProcessAnalytics iteratively (with the filters present on interface and with the filters obtained from the grouping report)
2. Using the todatasubset with the pagingInfo used in the grid, you should obtain the required data and provide it back to the grid.

In this way we should shield the actual a!queryProcessAnalytics call to original report by making use of the filters (user defined filters and with filters obtained from grouping report).

Mean while I present a psuedocode, I would like to give a hint - As and when the a!queryprocessAnalytics see the 10000+ index, it starts throwing an error. So the call to a!queryprocessAnalytics should be always shielded from sending an 10000+ index by opting for alternate approaches such as which we are discussing here. Simply speaking, as and when your pagingInfo is set to an index greater than 10000+, you should do as follows:
1. Fetch the whole dataset by calling a!queryProcessAnalytics iteratively (with the filters present on interface and with the filters obtained from the grouping report)
2. Using the todatasubset with the pagingInfo used in the grid, you should obtain the required data and provide it back to the grid.

In this way we should shield the actual a!queryProcessAnalytics call to original report by making use of the filters (user defined filters and with filters obtained from grouping report).