[wp-trac] [WordPress Trac] #61903: Unable to save draft when tab is open for a long time

[WordPress Trac]

#61903: Unable to save draft when tab is open for a long time
---------------------------+------------------------------
 Reporter:  janvandenberg  |       Owner:  (none)
     Type:  defect (bug)   |      Status:  new
 Priority:  normal         |   Milestone:  Awaiting Review
Component:  General        |     Version:  6.6.1
 Severity:  normal         |  Resolution:
 Keywords:                 |     Focuses:
---------------------------+------------------------------

Comment (by TJNowell):

 Encountered this on a client device, and managed to do some debugging:

 * This only affects chromium based browsers
 * But it can be reproduced using Firefox if max simultaneous connections
 is set to 1
 * Chromium error logs when the browser is launched in debug mode don't
 reveal anything
 * No server side errors, HTTP 504's, etc, it appears the requests are
 handled normally at the server end.

 Connections made via fetch and the apiFetch WP package don't appear to
 close properly after the request is completed. The socket remains open but
 does not get reused for new connections for some reason.

 When the socket pool reaches its maximum all new connections are stuck, be
 that WP Heartbeat or even dashboard pages in new tabs. This continues
 until the original tab is closed and a hard refresh occurs, or, the chrome
 socket pool is flushed, disconnecting all sockets.

 I managed to confirm this hypothesis using the net events recorder which
 confirmed that 6 sockets remained open and unused in the socket page of
 the net event viewer.

 Of note, although WP heartbeat connections failed, they would timeout at
 30 seconds whereas connections attempted via apiFetch to the REST API
 would remain stalled/pending. This lead us down a rabbit hole theorising
 that WP Heartbeat was using up available sockets, but this was a dead end
 and incorrect. We also confirmed the 30s was not due to something server
 side but a hardcoded value in the heartbeat JS.

 ----

 We managed to work around this by introducing a middleware that added a 30
 second timeout via an abort signal to all REST API calls:

 {{{
 import apiFetch from '@wordpress/api-fetch';

 /**
  * Add a 30s timeout to all API fetches so that sockets get freed up.
  */
 apiFetch.use( ( options, next ) => {
         return next( {
                 ...options,
                 signal: AbortSignal.timeout( 30000 ),
         } );
 } );

 }}}

 We weren't expecting this to resolve the issue though, and expected it
 would make the block editor indicate there was an error rather than
 getting stuck. Perhaps this changed the handling of the socket in
 chromiums net stack enough to avoid the issue? I suspect an equivalent bug
 is being tracked somewhere on the chromium bug tracker.

 We also theorise that because the connections are made over HTTP 1.1 that
 upgrading to HTTP/2 would help here, but we've been unable to verify this
 as it involves an approval process and multiple departments.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/61903#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform