Getting lots of <Response 504> errors.

[DLBerger]

I seem to get for following on many files:

Traceback (most recent call last): File "/home/dberger/degoo.DLBerger/./degoo_put", line 286, in sys.exit(main()) File "/home/dberger/degoo.DLBerger/./degoo_put", line 211, in main result = degoo.put(args.local, args.remote, args.verbose, not args.force, args.dryrun, args.scheduled) File "/home/dberger/degoo.DLBerger/degoo/util.py", line 1156, in put return put_directory(local_path, remote_folder, verbose, if_changed, dry_run, schedule) File "/home/dberger/degoo.DLBerger/degoo/util.py", line 1134, in put_directory put_file(Name, IDs[relative_root], verbose, if_changed, dry_run, schedule) File "/home/dberger/degoo.DLBerger/degoo/util.py", line 1035, in put_file degoo_id = api.setUploadFile3(filename, dir_id, verbose, Size, Checksum) File "/home/dberger/degoo.DLBerger/degoo/API.py", line 795, in setUploadFile3 raise self.Error(f"setUploadFile3 failed with: {response}") degoo.API.API.Error: setUploadFile3 failed with: <Response [504]> degoo_put: setUploadFile3 failed with: <Response [504]> for help use --help

Any idea what it means?

[bernd-wechner]

Well 504 is a timeout error:

https://www.howtogeek.com/367129/what-is-a-504-gateway-timeout-error-and-how-can-i-fix-it/

which suggests the Degoo server is down or not easy to reach from your end. Warrants a nicer message if it happens a lot, I've never seen it. This also happened in setUploadFile3:

https://github.com/bernd-wechner/Degoo/blob/5185deb521a4b680edcb5fa8ea030491293af26f/degoo/API.py#L715

Which was under put_file and hence came after the file was actually uploaded and is the call made to register the success of the upload with Degoo.

[DLBerger]

It is times for retries, especially on timeout errors?

[bernd-wechner]

Could be. Albeit probably with a command line option requesting it. Some timeouts are ephemeral and by sitting in a retry loop can provide a response in "real" time (meaning withing ones patience limits). Others don't ... I imagine:

1. A clearer message on a server timeout
2. A command line option requesting retries - with an optional integer count (if not supplied, and endless loop)
3. A retry loop that respects that command line option (runs when requested for as often as requested) and:
   • if running verbose reports each retry effort with timings.

[bernd-wechner]

Any more news on this?