we've run into quite serious bug last week, listing tasks in our application. The scenario is following:
We have tasks, each with 33 variables.
When listing all of the tasks (it's more than 700 tasks), we get only 607 of them.
When listing tasks (same query) but with offset 600, we get only 7 of them.
After deep investigation, we've found out an internal 20 000 limit, applied to the query. And after this result set, outer-joined with all the variables is returned, the limit & offset is applied.
This caused that only first 607 tasks are get. Because each one of them has 33 variables, 33*607 = 20 031. And the same explains why after offset 600 is required, only 7 of them are retuned.
Moreover, the 607th task (or 7th task in the offset query) contains less than 33 variables, just a subset of them (2 variables I guess, since 20000 - 606*33 = 2).
We consider this behaviour as a serious bug, as user is unable to get more tasks than ( #of variables per tasks x #number of tasks).
Moreover, the query generated is very inefficient, as all the variables are resolved, including the binary ones, also for tasks which are not returned.
Our "workaround" is way faster than original query and we consider it as a fix. It's simply fetching tasks without variables, and after they are retrieved, fetching their variables one by one. This approach is way faster and "fixes" the 20 000 hard internal limit.