Desktop time-out when synchronising large attachments from Joplin Server

[kckleong]

Operating system

Windows

Joplin version

3.0.13

Desktop version info

Joplin 3.0.13 (prod, linux)

Client ID: b542ac283077423b9e9e96dda6ddaa4b
Sync Version: 3
Profile Version: 47
Keychain Supported: No

Revision: 599cf5b

Backup: 1.4.1
Favorites: 1.3.2
Note list (Preview): 1.0.0

Current behaviour

I am seeing sync errors on the Windows and Linux beta clients that are Joplin Server-synced for attachments larger than about 20Mb.

After the Synchronise button is clicked, the orange "Some items cannon be synchronised." banner appears.

Clicking on the bar displays the sync status page with messages of the following form:

My Mate Manners - 20190408 - Final.zip (ab2702a244100fed72865510d4a9347c): Request timed out. Timeout value: undefinedms.

There are no problems on the Android beta or on the release desktop clients (e.g. Linux 2.14.20). Encryption is disabled.

The version are:

Android client: 3.0.8
Windows and Linux clients: 3.0.13
Joplin Server: 2.14.2-Beta (behind NGINX reverse-proxy)

It appears that the HTTP time-out option is being set to undefined and this is resulting in a very short value being used.

In packages/lib/shim-init-node.ts:

Line 518: 		if (!options.timeout) options.timeout = undefined;

I have patched the build to use the default value of 120000 ms, which resolves the problem i.e. the attachment are correctly synchronised from server resources.

I have previously reported this on Discourse but this seems to be a more appropriate forum.

Thank you all for your amazing work on Joplin!

Expected behaviour

Synchronise the server attachment to local storage.

Logs

No response

[pedr]

I don't understand how the timeout option could cause this behaviour, but maybe I'm just missing something @kckleong

When we set http.request(url, { timeout: x }) we are saying that this connection shouldn't be kept after x milliseconds, by having it as undefined the connection will be up until the server terminates it (which seems to be the correct behaviour, since if you are downloading a large file 120 seconds might not be enough).

That makes me think that we can't really choose a good value for timeout, but when I try to understand why the related issue exist I can't find the reason why it happens. From my testing with the clipper (which uses fetchBlob to download images) it seems like the request timeouts within 5 seconds, but I can't find the place where this is set or if there is another thing affecting this part of the code.

Vocabulary

• Keep-alive is a way for the client/server to keep the current socket/TCP connection open so subsequent requests can use the same connection, decreasing the time between connections, not very useful for this case.
• Timeout value should only matter before the connection is established. The client should never "timeout" of a working connection
• options.timeout it refers on how long the socket associated with the request can exist
• request.setTimeout how long the request can take, after the connection is established, so it seems like that there is no reason to have a request.setTimeout value higher than the options.timeout [4]

[pedr]

Other services timeout policy:

I don't think this is relevant anymore, but since I already wrote it down

I tried researching the value used in other services, for Dropbox and OneDrive/Microsoft Graph API there isn't any public information. I only found that the Dropbox SDK for Python has a default value of 100 seconds [1]

I don't think there is any default value for S3 bucket either, terraform uses a default 20 minutes for reads [2] but I haven't found anything on AWS documentation about how to set this value directly on the bucket.

Nextcloud has a 30s value [3] for a value that I'm not sure if is used for client-server connection (I think it is, I found the PR and it seems that this config affects cURL requests also) since the comment talks about federation between servers.

Chrome has 5m, Firefox 90s

[1] https://dropbox-sdk-python.readthedocs.io/en/latest/api/dropbox.html#dropbox.dropbox_client.Dropbox
[2] https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/s3_bucket
[3] https://github.com/nextcloud/server/blob/master/config/config.sample.php#L341
[4] nodejs/node#52576

[pedr]

• The issue didn't happen before because we didn't have an event catcher for the 'timeout' event.
• It is a client thing, a configuration for the client to decide that shouldn't keep waiting for the server.
• It seems like timeout means "socket has been inactive", probably meaning that either the server stopped sending information or the user connection is spotty for x seconds the connection is dropped https://nodejs.org/api/http.html#event-timeout
  • I could not test it that if something is being transferred and it is taking more than 5s the connection is not dropped (it would be more frequent that more users would have noticed? probably)
  • When I created a local server with a sleep function it would drop the connection after 5s
  • A server designed to load the file in memory before returning in the request might cause this timeout also (connection is established, but client doesn't get new data for x seconds)
• Using a requestOptions.agent = undefined we are opting to use the globalAgent which has a timeout of 5s, so that is why in my test the connection drops out after 5s
• If we create a new agent on each

[pedr]

• Just set a timeout a very high value (60 seconds)