Error when sending a form response

Hello,

I am working for a public entity that is using ODK to host a set of surveys that were designed as XLSForms and are already published and working in the organization’s domain. While the form can be accessed through the public link in any browser without problem, we have been getting this error message when we send a response to some of the forms; specifically, those that allow us to attach files along.

We tried to check every post and the official documentation, but we could not find any reference to this error: “Incorrect Sending/Delivery: signal is aborted without reason”

Also to clarify, we are located in a Spanish-speaking country, hence why some of the content is in Spanish. I have translated what I consider is relevant in the error message.

2. What steps can we take to reproduce this issue?

We are simply answering the questions as with the other forms and uploading files where asked to, those files are always PNG images, and their individual sizes are never exceeding 100MB, not even 2MB since they are light files.

Overall, the form is programmed to accept as many images as needed. The determining question asks for a number of processes to be revised, and based on said number, N fields are created to upload a different image in each.

Then we click on the submit button at the end and, after waiting for a prolonged period of time (on average, 1-2 minutes of the spinner saying it is being sent), the error appears and no information is collected and stored in ODK Central.

3. What have you tried to fix the issue?

Before, the message was a timeout message. So we changed our network to one with a speed of ~46Mbps and we closed browser, clearing cache. After this was done, the timeout message no longer appeared and this signal error message is shown instead. Nothing was changed in the XLSForm whatsoever.

4. Upload any forms or screenshots you can share publicly below.

Screenshot was shared before, but I think to clarify our setup:

  • Custom server with Ubuntu 22.04 LTS and 12GB RAM
  • Set with custom SSL, having created our own cert.pem and key.pem so that certificates match the organization’s available subdomain
  • Database is also custom, being set in a separate server following the process described in the custom DB setup official documentation.
  • We believe all of this is correctly set since other forms work fine, and we can create and administer new users without any problem. Besides, we can access the form and ODK Central correctly so domains and certificates are fine.
  • To comply with the organization’s WAF security policies, we made some adjustments to common-headers.conf and nginx.conf files, in order to modify a couple of headers.

I hope this was clear enough.

Thanks in advance for any help anyone can provide.

What version of Central are you using?
What specific changes did you make to the .conf files?
If you rollback the changes do the problems go away?

The version is
54932106a7cabc9378fc6da0213b414ba378ac44 (v2026.1.2-8-g5493210)
56b6bbdb4cac59aa850e3ddd1cd19ab9f2be1af3 client (v2026.1.2)
142c1c85501d90d225116862ba79dd914c5fcfc1 server (v2026.1.1)


The changes were done in:

  • common-headers.conf

Change line 10
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;

  • odk.conf.template

Change line 110

ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:
            ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:
            DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers on;

Insert after line 168

proxy_cookie_flags cookiesession1 secure samesite=strict;

Insert after line 210

location ~ ^/v\d+/sessions/restore {
    add_header X-Frame-Options SAMEORIGIN always;
    add_header X-Content-Type-Options nosniff always;
    proxy_pass http://service;
}
  • docker-compose.yml

Removed all references to postgres14 container since it is no longer used, database is now external custom server.


As for rollback, corporate has not allowed us to perform the operation, but I agree it is a necessary step to check functioning. We are limited to what we have, at least for the mean time.

Furthermore, I provide the message that appears in the browser console when the error occurs:

Checking in the network tab, comparing with a submission from a different form that works correctly, it appears as if it did not send the POST /-/submission/{{id}} request. It is the only difference between both traces.