[NOT_REPRODUCIBLE] Consecutive actions with backup have blocked/broke backups

I have…

I’m submitting a…

  • [ ] Regression (a behavior that stopped working in a new release)
  • [x] Bug report
  • [ ] Performance issue
  • [ ] Documentation issue or request

Current behavior

Broke the backup functioning, it’s like this now:

which runs undefinetely and at deletion responds with 404 Not found

Expected behavior

Being able to Delete the running Backup
Is there any way to flush such process?(I’ve tried stopping and restarting the container without success)

Minimal reproduction of the problem

  1. Start the lowest bottom(4th in my case) backup deletion
  2. Soon after press “Start Backup”
  3. Soon after meanwhile running the new backup clicking on “Delete”
  4. Deletion failed


App Name: collanon

  • [x] Self hosted with docker
  • [ ] Self hosted with IIS
  • [ ] Self hosted with other version
  • [ ] Cloud version

Version: 6.3.0


  • [ ] Chrome (desktop)
  • [ ] Chrome (Android)
  • [ ] Chrome (iOS)
  • [x] Firefox
  • [ ] Safari (desktop)
  • [ ] Safari (iOS)
  • [ ] IE
  • [ ] Edge

Now clicking on Start Backup again it did seem to clear the running backup

Do you have any exceptions in the log?

I cannot reproduce it, unfortunately.

I figured out what it is, it’s the caching of the json answers from /backups GET call. The response from that call sets the cache-control header and the Firefox does cache that answer, which doesn’t provide an up to date actions results.

I guess the solution would be to remove that caching. On my side my nginx reverse proxy doesn’t manipulate the squidex headers.

Squidex does not cache anything here. The explanation also does not make sense for me, because the backup is a single threaded grain, which should not have any concurrency issues.

Still, some logs would help.