I proposed a possible fix for this on the task you merged: https://gerrit.wikimedia.org/r/521575

Seen again today when using Flow.

Failed to load resource: net::ERR_SPDY_PROTOCOL_ERROR

https://www.mediawiki.org/w/load.php?lang=en&modules=diffMatchPatch%2Cpapaparse%2Crangefix%2Cspark-md5%2CtreeDiffer%2Cunicodejs%7Cext.CodeMirror.lib%2CvisualEditor%7Cext.CodeMirror.mode.mediawiki%7Cext.CodeMirror.visualEditor.init%7Cext.abuseFilter.visualEditor%7Cext.cite.styles%2CvisualEditor%7Cext.cite.visualEditor.core%2Cdata%7Cext.citoid.visualEditor%7Cext.citoid.visualEditor.data%7Cext.confirmEdit.visualEditor%7Cext.disambiguator.visualEditor%7Cext.flow.visualEditor%7Cext.flow.visualEditor.icons%7Cext.geshi.visualEditor%7Cext.graph.data%2CvisualEditor%7Cext.kartographer%7Cext.kartographer.editing%2Cutil%2CvisualEditor%7Cext.math.styles%2CvisualEditor%7Cext.score.visualEditor%7Cext.score.visualEditor.icons%7Cext.spamBlacklist.visualEditor%7Cext.templateDataGenerator.editPage%7Cext.titleblacklist.visualEditor%7Cext.visualEditor.base%2Ccore%2Cdata%2CdesktopTarget%2Cdiffing%2Cicons%2Clanguage%2Cmediawiki%2CmoduleIcons%2CmoduleIndicators%2Cmwalienextension%2Cmwcore%2Cmwextensionmessages%2Cmwextensions%2Cmwformatting%2Cmwgallery%2Cmwimage%2Cmwlanguage%2Cmwlink%2Cmwmeta%2Cmwtransclusion%2Cmwwikitext%2Cwelcome%7Cext.visualEditor.core.desktop%7Cext.visualEditor.mwextensions.desktop%7Cext.visualEditor.mwimage.core%7Cext.wikihiero.visualEditor%7Cext.wikimediaEvents.visualEditor%7Cmediawiki.action.view.redirectPage%7Cmediawiki.interface.helpers.styles%7Cmediawiki.language.names%7Cmediawiki.page.gallery.styles%7Cmediawiki.widgets.MediaSearch%7Coojs-ui.styles.icons-location%2Cicons-wikimedia&skin=vector&version=12hgy8c

The patch from the other task was merged: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/VisualEditor/+/521575

If the problem stops occurring, that will mean it was caused by the extremely long responses previously generated by VE.

At T232252, @Agusbou2015 wrote:

I click on "Publish changes" (on any Wikimedia project) and changes are not saved.
Steps to reproduce:

1. Open: https://es.wikipedia.org/wiki/The_Living_Daylights_(canci%C3%B3n)
2. Click on: "Editar código" (Edit code)
3. Click on: "Publicar cambios" (Publish changes)
4. Changes won't be saved and a DNS message (ERR_SPDY_PROTOCOL_ERROR) error appears.

Expected result: Clicking "Publish changes" (on any Wikimedia project), changes should be saved and no error message should appear.
Actual result: Clicking "Publish changes" (on any Wikimedia project), changes won't be saved and ERR_SPDY_PROTOCOL_ERROR appears.

Has anyone seen this issue again in the past two weeks? If not, the VE patch might have fixed it…

Well, since that apparently fixed the problem, we should probably consider a more general solution that would limit the maximum size of load.php responses.

@matmarex i think at the very least, when we trip the limit, we would want to have that proactively logged, regardless of the solution ?

I recall seeing it on other/smaller responses as well, but haven't seen those recently.

In T220022#5524618, @matmarex wrote:

Well, since that apparently fixed the problem, we should probably consider a more general solution that would limit the maximum size of load.php responses.

Yep, I'm also considering this for performance as there's some evidence suggesting that splitting the payload might result in quicker execution due to the compilation and stream-parsing not being as efficient in browsers as parallelising them manually as two separate ones. This is mostly anecdotal though, so worth putting some research into. We could then e.g. communicate in some fashion the rough ballpark size of a module (e.g. <=1K, <=10K, <=100KB, <=1MB, >1MB). And let mw.loader use that (in addition to domain and cache-group sharding) to split requests in such as way as to not ask for more than X in a single request. Perhaps using a 1 char-suffix in the version hash or something like that.

In T220022#5526897, @TheDJ wrote:

@matmarex i think at the very least, when we trip the limit, we would want to have that proactively logged, regardless of the solution ?

I'd like that. But, we don't yet know what the limit is (assuming it is deterministic by size, which might not be the case, e.g. could become gradually more common as size grows). And from what I know at this point, it is likely not easily detectable on either client or server side. To be continued :)