Do not show disconnected icon when Retry-After is sent with a 503

[butonic]

Expected behaviour

When the server responds with a 503 Service Unavailable message that contains a Retry-After: 120 header the client should silently wait 120 seconds before trying the same request again.

Actual behaviour

On a 503 the client changes the icon to represent a disconnected state. The Retry-After header is ignored.

Motivation

I am looking into integration with backup systems that will move old files off to a slower medium. The file may be available only after a few minutes. I would like to tell the client to just try again after a while without showing the disconnected icon to users, making them worry something is broken when actually miracles happen in the background to make them happy.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[dragotin]

@butonic are you able to create a client logfile of this case? That would help.

[ogoffart]

This would be a reply to what kind of command? PROPFIND? GET? PUT? something else?

[butonic]

@ogoffart a GET request for a single file. Nothing else.

[butonic]

@dragotin is this the relevant part?

10-08 17:18:44:063 0x1e3a1e0 Sync state changed for folder  "ownCloud" :  "Sync Running" 
10-08 17:18:44:063 0x1e3a1e0 virtual void OCC::PropagateDownloadFileQNAM::start() "Neue Textdatei.txt" 0 
10-08 17:18:44:063 0x1e3a1e0 "INSERT OR REPLACE INTO downloadinfo (path, tmpfile, etag, errorcount) VALUES ( ?1 , ?2, ?3, ?4 )" "Neue Textdatei.txt" ".Neue Textdatei.txt.~7f56db30" "561689194b57b" 0 
10-08 17:18:44:064 0x1e3a1e0 void OCC::SyncJournalDb::commitInternal(const QString&, bool) Transaction commit  "download file start" and starting new transaction 
10-08 17:18:44:064 0x1e3a1e0 virtual void OCC::GETFileJob::start() OCC::BandwidthManager(0x2faa838) false false 
10-08 17:18:44:064 0x1e3a1e0 !!! OCC::GETFileJob created for "http://localhost/core-stable81" + "/Neue Textdatei.txt" 
10-08 17:18:44:069 0x1e3a1e0 * Discarded as is hidden! "/home/jfd/sync/stable81/.Neue Textdatei.txt.~7f56db30" 
10-08 17:18:44:089 0x1e3a1e0 void OCC::AbstractNetworkJob::slotFinished() 301 "Error downloading http://localhost/core-stable81/remote.php/webdav/Neue%20Textdatei.txt - server replied: Service Unavailable" QVariant(int, 503) 
10-08 17:18:44:089 0x1e3a1e0 void OCC::PropagateDownloadFileQNAM::slotGetFinished()  QUrl( "http://localhost/core-stable81/remote.php/webdav/Neue Textdatei.txt" )  FINISHED WITH STATUS 301 "Error downloading http://localhost/core-stable81/remote.php/webdav/Neue%20Textdatei.txt - server replied: Service Unavailable" 0 0 3 0 "" "" 
10-08 17:18:44:090 0x1e3a1e0 "DELETE FROM downloadinfo WHERE path=?1" "Neue Textdatei.txt" 
10-08 17:18:44:090 0x1e3a1e0 void OCC::SyncEngine::slotItemCompleted(const OCC::SyncFileItem&, const OCC::PropagatorJob&) "Neue Textdatei.txt" INSTRUCTION_SYNC 1 "Error downloading http://localhost/core-stable81/remote.php/webdav/Neue%20Textdatei.txt - server replied: Service Unavailable" 
10-08 17:18:44:091 0x1e3a1e0 SocketApi:  Sending message:  "STATUS:ERROR:/home/jfd/sync/stable81/Neue Textdatei.txt" 
10-08 17:18:44:091 0x1e3a1e0 void OCC::SyncEngine::slotItemCompleted(const OCC::SyncFileItem&, const OCC::PropagatorJob&) "" INSTRUCTION_NONE 0 "" 
10-08 17:18:44:092 0x1e3a1e0 SocketApi:  Sending message:  "STATUS:OK:/home/jfd/sync/stable81/" 
10-08 17:18:44:095 0x1e3a1e0 void OCC::SyncJournalDb::walCheckpoint() took 0 msec 
10-08 17:18:44:095 0x1e3a1e0 void OCC::SyncJournalDb::commitInternal(const QString&, bool) Transaction commit  "All Finished." 
10-08 17:18:44:095 0x1e3a1e0 CSync run took  98 
10-08 17:18:44:095 0x1e3a1e0 virtual OCC::BandwidthManager::~BandwidthManager() 
10-08 17:18:44:096 0x1e3a1e0  - client version 2.0.1  Qt 4.8.6 
10-08 17:18:44:096 0x1e3a1e0 -> SyncEngine finished with ERROR, warn count is 1 
10-08 17:18:44:096 0x1e3a1e0 Processing result list and logging took  0  Milliseconds. 
10-08 17:18:44:096 0x1e3a1e0 OO folder slotSyncFinished: result:  3 
10-08 17:18:44:096 0x1e3a1e0   ** error Strings:  ("Error downloading http://localhost/core-stable81/remote.php/webdav/Neue%20Textdatei.txt - server replied: Service Unavailable", "Neue Textdatei.txt: Error downloading http://localhost/core-stable81/remote.php/webdav/Neue%20Textdatei.txt - server replied: Service Unavailable") 
10-08 17:18:44:096 0x1e3a1e0     * owncloud csync thread finished with error 
10-08 17:18:44:097 0x1e3a1e0 the last 2 syncs failed 
10-08 17:18:44:097 0x1e3a1e0 SocketApi:  Sending message:  "STATUS:ERROR:/home/jfd/sync/stable81/" 
10-08 17:18:44:097 0x1e3a1e0 SocketApi:  Sending message:  "UPDATE_VIEW:/home/jfd/sync/stable81/" 

It actually shows an error :/

[bboule]

@butonic Labeled a green ticket but seems neglected... Please assist in helping me understand the urgency here?

[MTRichards]

What do you guys think? @dragotin is this reasonable for 2.2?

[butonic]

Still active, but I think there was already a related mechanism for storages that may be unavailable...

[dragotin]

@butonic can you explain what happens with the current client? If the reply is 503 for a certain file, we try to download it next again, right? What is wrong with that? Well, maybe we blacklist the problem after a couple of retries, but that could be changed for 503.

The current architecture makes it very hard to "wait" for a certain time and try again.

[ogoffart]

Since the blacklist is time base, we could just blacklist for a given amount of time.

[butonic]

The use case is that the requested file might need to be retrieved from tabe, which might take 2-10 min. Since this is an expected unavailability for a GET request I think the client should not show an errer icon. Wasn't there some error code that would allow that behavior? I think it was introduced for federated sharing or something. I can also try to send that error code.

[butonic]

So the current implementation will silently ignore a 503 when accessing a file and just ry to download the file on the next sync? It will not interrupt the current sync but basically just skip the file? No change of the status icon? That would solve this issue and also a few other scenarios I have in mind.

[ogoffart]

The current implementation will treat it as an error, put it in the blacklist for 5 seconds. in a later sync (which is much likely more than 5 seconds away) it will try again to sync it, if it fails again, it will be blacklisted for 30 seconds. Then 2.5 minutes, then 15 minutes, then one hour, then 5 hours, then 25 hours (factor 5 each time).
But it will show an error.

I'm saying that from memory, i did not test actual file.

So we need to do something here not to show the error, and to blacklist the right amount of time directly.

[felixboehm]

@butonic Solved or Next Steps ?

[ogoffart]

@butonic is this still needed? Should I add special handling for the Retry-After tag?
Is there a way for me to get this error?

[guruz]

In #6906 this is now instead done by checking if the 503 is for maintenance mode or not.