Server timeouts out on endpoint GET /api/v2/open-data/<uuid>/data?page=1 when only 1 submission is present

[kelvin-muchiri]

Environmental Information

• Onadata version: 3.9.0

Problem description

There exists a peculiar intermittent bug where after applying pagination on the GET api/v2/open-data/<uuid>/data endpoint, the server timeouts if the number of submissions is one but seems to have no problem if the number of submissions is more than 1

Expected behavior

If there is only one submission and pagination is applied, the endpoint should return successfully with a response of 1 record

Steps to reproduce the behavior

The behaviour is tricky to reproduce and only occurs in some instances. At the moment, it is not known under which conditions/environments under which the bug appears.

Option 1

To reproduce the issue, create an OpenData object whose content_object is an XForm with only one submission then make a request to GET /api/v2/open-data/<uuid>/data?page=1. The server timeouts. Now, add another submission then make another request, the server returns a successful response.

Option 2 (Advanced)

Another way to reproduce the bug is running the commands in the Django interactive shell that represents the code execution for request GET /api/v2/open-data/<uuid>/data?page=1 as implemented in the TableauViewSet class and StandardPageNumberPagination class upto the point where the pagination is applied.

SSH into the instance experiencing the issue and open the Django interactive shell and run the following commands:

>>>  from onadata.apps.logger.models import OpenData
>>>  obj = OpenData.objects.get(uuid=<uuid>)
>>>  xform_id = obj.content_object.pk
>>>  from onadata.apps.logger.models import Instance
>>>  instances = Instance.objects.filter(xform_id=xform_id, deleted_at__isnull=True).order_by('pk')
>>>  instances[0:1]

The above commands reveal that code execution get stuck when the pagination class is performing the slicing operation on the queryset.

Repeat the above commands on an a form with more than 1 submission. Interesting discoveries emerge.

The following commands are successful:

>>> instances[0:]
>>> instances[1:2]
>>> instances[1]
>>> list(instances[0])

The following commands get stuck in execution:

>>> instances[0]
>>> instances[0:1]
>>> instances.first()
>>> instances.last()

So far, the conclusion is that the bug mainly shows up when trying to access the first item of the queryset

Additional Information

Logs, related issues, weird / out of place occurrences, local settings, possible approach to solving this...