Statuses endpoint failed on submission made via ODK

[NSUWAL123]

Describe the bug
/Statuses endpoint throws 500 error after building submission made via ODK.

To Reproduce
Steps to reproduce the behavior:

1. Create a project
2. Go to project-details page (Here the /statuses endpoint is hit and the response status is 200)
3. Go to ODK and make a submission
4. Go to or Refresh the project-details page and see 500 error on /statuses endpoint

Expected behavior
/statuses API should not throw a 500 error even if a submission is made.

Screenshots
If applicable, add screenshots to help explain your problem.
Before submission was made:

After submission was made:

Smartphone (please complete the following information):

• Device: [Laptop]
• OS: [Ubuntu]
• Browser [Google Chrome]
• Version []

Additional context

[Sujanadh]

endpoint works fine, but when submission is made how odk collect sends status to the odk central? it is passing quoted task status . For eg: 'status' : ' "2" '.

[Sujanadh]

@spwoodcock

[spwoodcock]

Interesting!

The integer value needs to be quoted, as Entity fields can only be string type.

But it looks like double quoting that needs to be fixed.

Not sure why that would cause a 500 though!

[Sujanadh]

Got a validation error since the quoted index won't match the enum.

[spwoodcock]

Fantastic - great debugging!

Do you think this could be caused by the XLSForm?

The status field defaults to "2" and the calculation logic is if(${digitisation_correct}='no', "6", "2")

My assumption is that there is already logic in ODK Collect to wrap the values in quotes before sending to Central.

[NSUWAL123]

@spwoodcock, currently the /statuses api would return thousands of statuses of features of the entire project.
Is this approach good? As we have to filter that thousands of buildings status to colorize each feature.

Is returning the statuses of the features bound to that task would be a good approach? like when a user clicks a task then /statuses endpoint is called with a filter of taskId

[spwoodcock]

It's not so easy to do that unfortunately, as the odata endpoints for ODK Central a bit limited in their filtering capability.
Perhaps this may change in the future and we can consider updating.
But for now we are kind of stuck with it 😅

Are you seeing performance issues with the approach?
The endpoint takes about 0.3s to return for 600 features when testing, the payload is about 60kb.
So imagining this scales linearly, that would be 3s for 6000 features, and 600kb.
If the user is mapping 6000 features in one campaign, it's probably better they subdivide further into districts!

[NSUWAL123]

It wastn't a performance issue. It was the issue with debug console😆. I had consoled inside the getFeatureStyle where the website was too much laggy and unresponsive during console. But consoling after debug commenting console woked perfectly fine.
But as you said in future we also need to consider project with too many features as well.