Page MenuHomePhabricator

Fix a Mercurial wire protocol parser issue when we receive a length frame before any data

Authored by epriestley on Jan 4 2018, 9:46 PM.
Referenced Files
F11049358: D18857.id45237.diff
Fri, Aug 19, 1:51 PM
Unknown Object (File)
Thu, Aug 18, 3:47 AM
Unknown Object (File)
Tue, Aug 16, 10:04 AM
Unknown Object (File)
Wed, Aug 3, 2:14 AM
Unknown Object (File)
Mon, Aug 1, 11:11 PM
Unknown Object (File)
Wed, Jul 27, 8:57 PM
Unknown Object (File)
Fri, Jul 22, 2:47 AM
Unknown Object (File)
Jul 3 2022, 3:11 AM



Depends on D18856. Ref T13036. See PHI275. When we receive a length frame but the buffer doesn't have any data yet, we currently emit a pointless 0-length data frame on the channel.

For normal chatter this is harmless/valid, but it causes problems when a channel has transitioned into bundle2 mode (probably it indicates "end of stream")?

In any case, it's never helpful, so if we're about to read a data block and don't have any data, just bail out until we see some more data.

Note that we can't end up here expecting a 0-length data block: both the data-length and data-bytes states already handle that properly.

Test Plan

Pushed 4MB changes to a Mercurial repository with Mercurial 4.1.1, was no longer able to hit channel errors.

Diff Detail

rP Phabricator
Lint Not Applicable
Tests Not Applicable

Event Timeline

epriestley created this revision.
  • Narrower explanatory comment.
amckinley added inline comments.

Not a huge deal, but for consistency with the other branches in this function, it would be nice to have a comment block here.

This revision is now accepted and ready to land.Jan 4 2018, 10:00 PM
This revision was automatically updated to reflect the committed changes.