🐛 Fix listJobs pagination bug

[lmossman]

What

I discovered a bug in the listJobs query that takes in a pageSize and offset. The issue is that this query first performs the join between jobs and attempts before applying the LIMIT and OFFSET, which means that LIMIT and OFFSET are applied to the result of the join, so they are actually limiting/offsetting into that join result.

Practically, this means that if some connection has the following job table setup:

(job 4: attempt 1, attempt 2, attempt 3)
(job 3: attempt 1, attempt 2)
(job 2: attempt 1)
(job 1: attempt 1, attempt 2)

Then the EXPECTED result of executing listJobs(limit: 2, offset, 1) is:

(job 3: attempt 1, attempt 2)
(job 2: attempt 1)

but the result that is actually returned due to this bug is:

(job 4: attempt 2, attempt 3)

because the limit and offset are applied to each job<>attempt pair.

How

This PR fixes the bug by changing this query to apply the limit and offset to the jobs table only in a subquery, which is the result of is then joined with the attempts table. This results in the expected behavior of limit and offset being applied at the job record level.

To accomplish this, I had to move the old BASE_JOB_SELECT_AND_JOIN value into a new method jobSelectAndJoin() that takes in the string to use as the job subquery. The paginated listJobs() method can then use this method and pass in its paginated jobs subquery into that method. Whereas BASE_JOB_SELECT_AND_JOIN just passes in jobs as the subquery, so that the resultant string for that constant is actually the same as it was before this change, which I wanted because basically every other query in this class uses that constant.

I also updated the test for this method to properly check that pagination is being performed correctly even when jobs have multiple attempts.

Recommended reading order

1. DefaultJobPersistence.java
2. DefaultJobPersistenceTest.java

🚨 User Impact 🚨

The impact of this change is that the pagination behavior of the listJobs API endpoint and query should now work as expected, in that pagination applied at the job level rather than at the (job, attempt) pair level.

[alovew]

lgtm 👍

[jdpgrailsdev]

A future warning for us: this is fine for now, but if/when the dataset grows large, OFFSET can have some real performance issues. The alternative is to filter using a key or ID, but that has its own problems. This also highlights the need to use pagination from an application framework so we can avoid having to solve this type of problem (e.g. let the framework handle how to generate a paginated query).

[lmossman]

Yep, I definitely agree that using an application framework to generate these queries for us would be greatly preferable. Looks like we also have an EPIC for API Pagination here - it may be a good idea for you to add a note there about avoiding OFFSET and doing a different pagination mechanism (e.g. cursor pagination)

[jdpgrailsdev]