I did a little investigation into this this morning.

Personally I couldn't reproduce.
I couldn't find any indication of mediawiki/wikibase doing anything wrong in logstash.
Special:EntityData which serves this URI is cachable in varnish so I decided to have a dig around in the webrequest logs for the time period that I believe we are talking about (13th Feb).

The sequence of cache hits looks a little odd to me with the first 9 or 10 cache hits all returning differing response sizes (from my knowledge I don't know why that would happen)
Once ached in the back layer of varnish the response size looks to be complete and consistent.

Had a little chat in IRC on operations and going to poke ops to have a bit of a closer look.

I haven't done any investigation yet, but it sounds similar to T215389.

Varnishlog of the varnish backend instance serving the request in esams reports the following:

-   ReqMethod      GET
-   ReqURL         /wiki/Special:EntityData/Q61707895.nt?cachebust=1551953444
-   ReqProtocol    HTTP/1.1
[...]
-   Timestamp      Fetch: 1551953445.508907 0.426942 0.426942
-   RespProtocol   HTTP/1.1
-   RespStatus     200
[...]
-   Debug          "Write error, retval = -1, len = 2437, errno = Connection reset by peer"
-   Timestamp      Resp: 1551953445.709184 0.627218 0.200252

Same error for the request reported in T215389:

-   ReqMethod      GET
-   ReqURL         /blubber/linux-amd64/blubber?cachebust=1551952223
-   ReqProtocol    HTTP/1.1
[...]
-   Timestamp      Fetch: 1551952223.603492 0.085144 0.085144
-   RespProtocol   HTTP/1.1
-   RespStatus     200
[...]
-   Debug          "Write error, retval = -1, len = 1362, errno = Connection reset by peer"
-   Timestamp      Resp: 1551952223.928025 0.409676 0.324517

Tickets merged as this very much looks like the same issue.

Those connection resets on the varnish backend layer happen when frontend caches are full and varnish cannot make space for a newly fetched object body:

--  ExpKill        LRU_Cand p=0x7f7bbc64f740 f=0x0 r=1
--  ExpKill        LRU x=980813893
# [...] the above happening 50 times, our current setting for nuke_limit
--  ExpKill        LRU_Exhausted
--  FetchError     Could not get storage
--  BackendClose   11217 vcl-ed50cc64-c0ad-4266-89a4-9e4539972e1a.be_cp3033_esams_wmnet
# varnish frontend closing the connection to varnish backend

Interestingly, the problem is not reproducible with larger objects, as varnish autonomously decides they're too large and does not cache them (see the "pass" entry in X-Cache):

$ curl -L --resolve releases.wikimedia.org:443:91.198.174.192 --http1.1 -v -o /dev/null https://releases.wikimedia.org/parsoid/parsoid_0.10.0all_all.deb?x=$RANDOM 2>&1 | egrep "Content-Length|X-Cache:"
< Content-Length: 46716380
< X-Cache: cp1077 pass, cp3033 miss, cp3033 pass

We are currently limiting the maximum object size on cache_upload frontends to 256K. The assumption was that cache_text would not really benefit from the cutoff given that the dataset is made of smaller objects (compared to upload). Let's add the limit to cache_text too.

Change 494937 had a related patch set uploaded (by Ema; owner: Ema):
[operations/puppet@production] varnish: apply frontend size-based cutoff to text too

https://gerrit.wikimedia.org/r/494937

In T216006#5008346, @ema wrote:

Interestingly, the problem is not reproducible with larger objects, as varnish autonomously decides they're too large and does not cache them

False! We do have misc VCL code in place to avoid caching objects larger than 10M.

Change 494937 merged by Ema:
[operations/puppet@production] varnish: text/misc frontend size-based cutoffs

https://gerrit.wikimedia.org/r/494937

Mentioned in SAL (#wikimedia-operations) [2019-03-13T08:51:14Z] <ema> cp3030: wipe frontend cache to get rid of large objects T216006

The issue should be fixed. @VladimirAlexiev, @Addshore: can you confirm?

It's fixed!