Re: [PATCH 4/9] run-command: add support for timeout in command finisher

[Junio C Hamano <gitster@pobox.com>]

Johannes Sixt <j6t@kdbg.org> writes:

> Am 21.05.26 um 11:59 schrieb Siddh Raman Pant:
>> The timeout is for the failure path, where the external helper has
>> already stopped following that protocol or is blocked on something
>> outside git's control. Since git starts the helper and puts it on the
>> log/grep path, git also needs a bounded way to recover when that helper
>> does not make progress. Otherwise an optional note source can prevent
>> the main git command from completing.
>
> That Git communicates with a process that looks like it stopped is the
> normal case, for example:
>
> - Output is sent to the pager. The user can take their time to study the
> output. All the while, git waits patiently for the user to advance the
> pager.
>
> - Git fetch transfers large amounts of data across the network. Most of
> the time it waits for data to arrive and does nothing. The peer process
> looks like it hangs. Git does not decide to kill the connection at any
> time. It is the user's decision to do so.
>
> If the notes provider hangs, then it is not on Git to decide when it has
> waited long enough.

It is often the sticking sore point that there is no good timeout
value that suites for everybody.

If a protocol builds its own way to declare "this backend is slow,
so please do not consider less than 3 seconds of nonaction something
to worry about but kill it off if you waited more than that" to make
the receiving/waiting end responsible for managing timeout, that
might be workable, but it certainly feels like a kludge.  The
protocol can instead allow an "error - for your particular request,
we couldn't come up with an answer within a reasonable time limit"
response (in practice, "within time limit" does not have to be the
only reason for such an error) to be returned, I think.