chore: remove Name_IPNISync from PingHealthFuncs

[beck-8]

No description provided.

[LexLuthr]

Why are we dropping IPNI from health check?

[beck-8]

@LexLuthr
Given that cid.contact fixed the cache problem yesterday. So I can say it here now.

if ipni is slow or has a cache problem, it will cause all SP pdp/ping 503, which is similar to an attack. So remove this part of the check from /pdp/ping.

[LexLuthr]

This is not as simple as just removing code to get rid of 503. This is a product decision. Either we stop caring about IPNI or we do. Either case this needs a much bigger buy-in as it has direct impact on FoC product.

[beck-8]

There is no lack of attention here, but the alarm reminder of downgrade to SP. Of course, there are indeed many people who have not configured the alarm.

When I asked this question, I simulated this kind of attack. The cache of IPNI was triggered, and then the two nodes of my test network could not provide external services.

I think we should pay asynchronous attention, and IPNI should not be allowed to block customers from using it here. I'm happy to receive more opinions.

[BigLep]

@beck-8 : I'm missing some of the context here. You mentioned a cache problem in FilOzone/filecoin-services#369 (comment). Where do I read more about this?

Is your cocnern that if cid.contact is down for a sustained period of time, then that will make it so all PDP SPs fail their health check and thus stop taking on deals?

I think it will help if you elaborate on the failure scenarios you are worried about. I think you could also outline the pros and cons of this code change or the existing system.

[beck-8]

more context: https://filecoinproject.slack.com/archives/C02T827T9N0/p1787987394240329?thread_ts=1787205796.137809&channel=C02T827T9N0&message_ts=1787987394.240329

[beck-8]

If this abnormal caching issue occurs again, or if IPNI runs slowly for more than 1 hour (/provider does not refresh), this problem will cause all SP health checks to return a 503 error.