Re: [PATCH GSoC v3 2/8] fetch-object-info: detect truncated server responses

On Mon Aug 3, 2026 at 8:18 PM CEST, Junio C Hamano wrote:
> Pablo Sabater <[email protected]> writes:
>
>> The loop reading the object-info response stops as soon as the reader
>> returns something other than PACKET_READ_NORMAL. A server that somehow
>> answers with fewer objects leaves the end of the result arrays empty.
>>
>> The caller trusts that every requested object will be filled in.
>>
>> die() if the loop doesn't reach the number of oids expected.
>
> This tightening is obviously a good thing to do.
>
> The above description makes me wonder what happens if the other side
> sends responses for more objects than we requested.  We allocate for
> N objects and loop for up to N iterations, so we will not read more
> than N.  But do we detect that we are out of sync when we read the
> response to our next request, or before we shut down the connection
> if we do not have any further requests?

As it is now we would only notice in the stateless case. The loop will
only go for N lines and then leave the rest unread, then
check_stateless_delimiter() reads the next packet and dies because it is
a normal packet. If it isn't stateless it will early return and we
won't notice.

There is nothing to get out of sync though. The connection is started
and finished for each remote-object-info command line. So a later
remote-object-info starts fresh.

But even if it is harmless (I think) it's not ideal and I didn't think
about this case. The fix should be easy, check the next packet for a
flush after iterating, otherwise die().

[snip]

Thanks,
Pablo