KPI Report fails with error: ValueError: invalid literal for int() with base 10: 'None'

[green3g]

Hi, I'm running into an issue with Kobo when accessing the endpoint for the report. When I navigate to the KPI UI for "Reports" I see a request to the URL that times out with error 504

/reports/<Form ID>/?names=

I got into the docker container for KPI and I'm seeing the following logs:

ValueError: invalid literal for int() with base 10: 'None'
WARNING:root:invalid literal for int() with base 10: 'None'
Traceback (most recent call last):
  File "/opt/venv/src/formpack/src/formpack/reporting/autoreport.py", line 76, in _calculate_stats
    values = list(field.parse_values(raw_value))
  File "/opt/venv/src/formpack/src/formpack/schema/fields.py", line 504, in parse_values
    yield int(raw_values)
ValueError: invalid literal for int() with base 10: 'None'
WARNING:root:invalid literal for int() with base 10: 'None'
Traceback (most recent call last):
  File "/opt/venv/src/formpack/src/formpack/reporting/autoreport.py", line 76, in _calculate_stats
    values = list(field.parse_values(raw_value))
  File "/opt/venv/src/formpack/src/formpack/schema/fields.py", line 504, in parse_values
    yield int(raw_values)
ValueError: invalid literal for int() with base 10: 'None'

Let me know if I can provide more information to help troubleshoot this.

[green3g]

Upon further investigation - it appears that this error is not actually causing a crash. But it does result in a 504 gateway timeout for some reason. While watching the logs I get that same error printed dozens of times. The request eventually fails, and eventually I see the logs output:

DAMN ! worker 1 (pid: 123) died, killed by signal 9 :( trying respawn ...
Respawned uWSGI worker 1 (new pid: 130)
worker 2 killed successfully (pid: 128)
uWSGI worker 2 cheaped.

[green3g]

Okay - I narrowed this down a little further after investigating the docker containers.

It looks like we have two cases that are causing issues:

1. literal text of None values in the form fields that are set to int
2. Decimal values in the form fields that are set to int

After discovering this - I think its actually quite related to the issue: #151

[green3g]

One final comment - to wrap this up -

Turns out the issue does not crash the server - but the python server does eventually kill the thread due to the request timing out. The large number of errors being logged apparently slows down the request and makes the server kill the thread.

Closing as a duplicate of 151