Routing.Type=auto: announcements over HTTP PUT cid.contact always fail

[lidel]

Version

0.18.0-rc1

Config

default produced by 'ipfs init' (Routing.Type=auto)

Problem

Only GET /routing/v1/providers/{CID} in IPIP-337 is currently supported by https://cid.contact/, and they have no short term plans to enable it.

At the same time, Kubo 0.18.0-rc1 running with Routing.Type=auto (default) sends HTTP PUTs that will always fail.

Solution

TBD, two obvious options come to mind:

• (A) disable announcing over HTTP in auto mode for now, we will enable it in the future release after cid.contact supports it
• (B) make it future-proof: detect IPNI being read-only (failing HTTP PUT multiple times) and temporarily block announcements on it (e.g. for 22h, to match default Reprovide.Interval)

I don't know how "stable" PUT /routing/v1/providers API is. If it is ready, then my vote would be to implement (B) in 0.18.0-rc2, as it is safer behavior that accounts for the slow rate of nodes updating to new versions of Kubo. (B) allows 0.18 nodes to start publishing as soon cid.contact supports it.

cc @ajnavarro @guseggert @willscott @masih

[ajnavarro]

I agree with B. We could use https://github.com/hashicorp/go-retryablehttp . Integration should be easy. WDYT?

[lidel]

Yes, that would mitigate temporary issues with HTTP, which feels useful, but may not be enough for (B).
We need to make it smarter than a retry-per-request-with-expotential-backoff: need additional global "cooldown" flag per HTTP endpoint that NEVER responded with success to a PUT. Such flag would disable PUTs for some time (22h) to avoid wasting resources on a useless endpoint.

[masih]

For reference IPNI will return 501 Not Implemented on PUT. That status code is not a retry-able error really, so maybe upon observing that status code the logic can aggressively increase retry intervals between consecutive PUTs, e.g. in order of days.

[guseggert]

I'm strongly favoring A) since B) makes a bunch of assumptions about how providing will work but we haven't really implemented and exercised it yet (to my knowledge?). I think we should treat the upgrade problem as a separate issue and favor incremental delivery of features instead of trying to front-load them.