QueryManagerImpl incorrectly hardcodes start page to 1

[tdiepenbrock]

We were experimenting yesterday with adding transaction awareness to our search requests.
(In a few places in the app, we open a transaction for a long request, write some data, then expect it to be available to read requests within the same transaction)

We changed from using this queryManager method:
queryManager.search(queryDef, searchHandle, start) (implemented at QueryManagerImpl:140)

to this one:
queryManager.search(queryDef, searchHandle, start, transaction) (implemented at QueryManagerImpl:161)

Line 162 is the problem: it calls search(queryDef, searchHandle, 1, transaction, null)
replacing the start value we pass with 1, for some reason.

This has the effect of always returning page 1, instead of the page we asked for, which gets us into an infinite loop situation.

Is this what’s supposed to happen with transaction-aware searches, or is this a bug?
If, as we suspect, it is a bug, when can a patch be issued?

As a workaround, we may be able to use the search function version which includes the forestName, passing null, and it looks like that ought to work.

[sammefford]

Thanks for reporting this, Tom!

[andreas-hu]

I've run into that bug as well and can confirm it. The workaround is usable.

[sammefford]

@georgeajit to test, please add a test for this override:

queryManager.search(queryDef, searchHandle, start, transaction)

And set start to something other than 1, then check that it correctly returns results starting at the specified start.