The default timeout for ipni CLI doesn’t seem to be honoured

[masih]

Reported when syncing very long ad chains:

The default timeout for ipni CLI doesn’t seem to be honoured. The command shows the timeout to be 10s but it wait for well over 1 minute before timing out. If I explicitly set the timeout to be 10s, then it seems to work.

Specific example:

• CID baguqeerawlmmxljdh2xl72eky7xkqntrdkjul5ayzhvklhgfnyckdzyiavcq
• Provider ID 12D3KooWCxU3TgQdcfkLegGr1YxvJn2x3Y3xfiUyTCA7V2rM6hAo

[gammazero]

The publisher address associated with that Provider ID, /ip4/202.181.153.253/tcp/3104/http/, is no longer reachable.

[gammazero]

Testing shows that the default timeout is correctly communicated to the ipni client and to go-libipni. The timeout is correctly set in the HTTP client used with libp2phttp for HTTP over libp2p.

The timeout does not appear to be propagated to libp2p reading data. This issue describes the problem: libp2p/go-libp2p#2533
Fixing this by adhering to the request context should fix the timeout handling.

There are other situations where the timeout is working but may not appear to work:

• When syncing an advertisement chain, each ad is fetched with a separate request. This means each fetch has its own timeout. If 10 ads take 5s each to fetch and fetching the 6th ad times out after 10s, it will appear to take 60s to timeout.
• Each multihash block is fetched with a separate request. If it takes 9s to request each of the first 3 blocks, and the 4th block fails due to timeout, it will appear to take 37s (9s+9s+9s+10s) to timeout, even though the timeout is 10s.
• A libp2p stream reset error is automatically retried once. The retry is a new request with a new timeout.

[masih]

CC @LexLuthr

[gammazero]

Fixed by libp2p/go-libp2p#2796