Not All Audio file get submitted through REST call back


Audio urls that come with the REST call back once an interview is submitted is missing some audio files

Steps to Reproduce

1- create a kobo survey with multiple audio fields
2. add REST Service api call
3- fill the survey with audio files(larger file sizes show this bug)
4. not all audio urls are pushed through attachments field but partial list

Expected behavior

All Audio files are with that api call back

I’m experiencing this same behavior on a form with multiple image files. This didn’t used to be an issue, but now it’s only including the attachment links for the first 2 or 3 image answers in the JSON being posted via the Rest service.

We should open an issue for this [you already did] but it’s not clear exactly how we would fix it. Enketo and Collect will send multiple POST requests, where each has the same submission XML and a subset of the attachments for that submission, when the attachment sizes get large enough. This is part of the OpenRosa specification that KoboToolbox and other software in the ODK ecosystem follow. Some details about this multiple-POST process are here:

Should we delay contacting the external REST Services endpoint until all media files are received for a particular submission? That doesn’t really seem right: there’s a chance that all those files will never be received.

I think your best option for a quick workaround is going to be polling the KoboToolbox data API until all the attachments appear. You could initiate the polling once REST Services has made you aware of a submission. It would be up to you to decide how long you want to keep retrying before giving up on receipt of any missing attachments.

cc @nolive

1 Like

Thank you for the explanation @jnm, that is helpful in understanding what is happening. I’d stayed out of directly accessing the API so far, but I guess I get to learn something new.

Am I correct in my understanding that this behavior will be more pronounced when the end user has a poor internet connection?

It seems like that’s true, but I’m not entirely sure why. I thought the clients’ decision as to how many attachments are included in the first POST was purely based on size, but perhaps they have some logic to retry with fewer attachments when the first request fails.

1 Like