Unexpected behavior with new timeouts: "zero" timeout despite long defaults

[nigoroll]

logging an issue found by @martin-uplex

Using this dynamic director

backend sslon {
   .path = "/tmp/varnish_sslon.proxy.sock";
   .connect_timeout = 5s;
   .first_byte_timeout = 20s;
   .between_bytes_timeout = 20s;
}

sub vcl_init {
   new https = dynamic.director(via = sslon, port = 443);
}

with these global timeouts

first_byte_timeout            300.000 [seconds]
idle_send_timeout             300.000 [seconds]
pipe_timeout                  300.000 [seconds]

and no vcl override of timeouts leads to behavior as if a 0 timeout was configured:

--- Timestamp      Fetch: 1715591622.154104 0.008790 0.000009
--- Timestamp      Connected: 1715591622.154129 0.008815 0.000025
--- BackendOpen    644 https.www.site.de(X.X.X.X:443) 0.0.0.0 0 0.0.0.0 0 connect
--- Timestamp      Bereq: 1715591622.154136 0.008822 0.000006
--- FetchError     first byte timeout
--- BackendClose   644 https.www.site.de(X.X.X.X:443) close Receive timeout
--- Timestamp      Beresp: 1715591622.155162 0.009848 0.001025
--- Timestamp      Error: 1715591622.155163 0.009849 0.000000 

The workaround is to set explicit timeouts in the director.

Probably related to a7059d4efab10a285c1f57f7e02bbe631cf3a649 / https://github.com/varnishcache/varnish-cache/commit/119056c4d9319155c6c6c2148519d2e8d81d5f76

[nigoroll]

The cause of this issue is that https://github.com/nigoroll/varnish-cache/commit/aea6047cfa65ad1daf77a6f0d3e4bf068ade5879 (based on https://github.com/varnishcache/varnish-cache/commit/7ba00a3f9a7b5452ea126d86fdb0dde0eea41810), was used with f38f2836e53f50238592c839f2be5a40b015b205, which has https://github.com/nigoroll/libvmod-dynamic/commit/a7059d4efab10a285c1f57f7e02bbe631cf3a649 - the new -1 defaults to timeouts. Yet the varnish-cache version used does not have the new semantics for -1.