Bug 2405328

This commit was reported in the linked issue as the one causing the issues:

https://github.com/curl/curl/commit/6080143f9d4f198901792f1365123f9aad166446

I had a closer look at the commit "multi: replace remaining EXPIRE_RUN_NOW" - https://github.com/curl/curl/commit/6080143f9d4f198901792f1365123f9aad166446. It was a part of a bigger effort to reduce the complexity of time management within curl.

Previously, libcurl would often clear its timer queue after an action, resulting in a timeout value of -1 (delete timer) being passed to the timerfunction callback.
With the new change, libcurl marks transfers as "dirty" and schedules an immediate callback to process them. Consequently, the timerfunction is now invoked with a timeout of 0 (execute immediately) instead of -1.

There is nothing to fix on the curl side, and from what I saw in ethon upstream, it should be sufficient to just fix the test to accept the new callback value.

Thanks for looking into the issue. I think I start to understand. However, the test is not very specific and therefore also your suggestion does not apply that easily, because in fact, with recent version of libcurl, there is checked something else then it should. Let me explain.

There is `calls` array. With libcurl 8.15, it contains two entries before the last check:

~~~
[0, -1]
~~~

However, with the libcurl 8.16+, there is just one entry:

~~~
[0]
~~~

So the difference is not that the return value differs, but the callback is actually not executed on `delete`. So is it expected?

IOW, if I understand correctly, the callback is executed by `Curl_update_timer` [3] call. So up until libcurl 8.15, this [4] would be the place within `curl_multi_remove_handle` (which corresponds to `multi.delete(easy)` in Ruby) from where the call back was executed. I wonder why it is not the case anymore.



[1]: https://github.com/typhoeus/ethon/blob/cb1d7ea0cda12762ed0c745b3d44839ac1d0bbab/spec/ethon/multi/options_spec.rb#L91
[2]: https://github.com/typhoeus/ethon/blob/cb1d7ea0cda12762ed0c745b3d44839ac1d0bbab/spec/ethon/multi/options_spec.rb#L103
[3]: https://github.com/curl/curl/blob/9c3fcb8a321882232409f9b05b07098821378219/lib/multi.c#L3442
[4]: https://github.com/curl/curl/blob/9c3fcb8a321882232409f9b05b07098821378219/lib/multi.c#L885

Just FTR, when the test was introduced [1], it looked like this:

~~~
      it "allows multi_code return values" do
        calls = []
        multi.timerfunction = proc do |handle, timeout_ms, userp|
          calls << timeout_ms
          :ok
        end

        easy = Ethon::Easy.new
        easy.url = "http://localhost:3001/?delay=1"
        multi.add(easy)
        expect(calls).to eq([0]) # adds an immediate timeout

        multi.socket_action
        expect(calls).to eq([0, 1]) # nothing was ready, so waits 1ms

        multi.delete(easy)
        expect(calls).to eq([0, 1, -1]) # cancels the timer
      end
~~~

IOW there was additional `multi.socket_action` call. In such scenario, the `.delete` still triggers the timer handler (while the results of `.socket_action` is 200 or 201, contrary to what the test case says). Later, the `.socket_action` call was removed [2].


[1]: https://github.com/typhoeus/ethon/pull/196/changes#diff-0b358d6777ba6b679e0449f157d2be3d87f5766b6b5c74ac067cfb20f6e56f46R76-R92
[2]: https://github.com/typhoeus/ethon/pull/200/changes#diff-0b358d6777ba6b679e0449f157d2be3d87f5766b6b5c74ac067cfb20f6e56f46L86-L89

I have reached out to the upstream for help. Here is the GitHub issue:

https://github.com/curl/curl/issues/20498

Fixed via bodhi update: https://bodhi.fedoraproject.org/updates/FEDORA-2026-4a0612590e