Pin status with retries

[hsanjuan]

Pin tracking should keep track of retries. It could stop retrying after certain amounts. It could tell how many times an item has been retried. etc.

[hsanjuan]

I can offer an approach to pin retry improvements after #1484 .

The pintracker can have several tracks (implemented as pin workers):

• Track A for pins that have been "recently" pinned
• Track B for pins that were pinned some time ago (i.e. > 24h ago)

This would put new-pins in "front of the queue". Pins that are older and that keep failing or retrying would still be retried but would end on a different queue. A "bump" could be performed by repinning.

A cluster peer restart, would not have to go through all the pins that have failed, as old ones would naturally end up in the Track B. The cluster would be able to start pinning newer pins using the specific Track A.

This is a low-complexity solution though and keeps the "stateless pintracker" stateless and changes are going to be quite self-contained.

---

The alternative is to add state to the tracker so that I can track metadata (how many times things have been retried etc). Cluster peers do not store anything other than the pinset (shared state, consensus). This requires permanent storage outside "shared state", which requires creating and using a new part of the datastore (namespace).

This is going to be specially problematic with raft, as raft nodes do not use a permanent ipfs datastore (instead deserialize the state into an in-mem datastore). We could say "raft doesn't support this", but in any case things get more difficult.

Once we had state for that, the "stateless" pin tracker would use that state to decide if something is worth retrying again. But of course we will need a way to tell it that something is indeed worth retrying, that something needs to be retried "now" etc. so there is a number of change in semantics that would need to get supported, potentially also ending up in a pinning multi-track solution.

---

@alanshaw thoughts? Do you think the first option could actually alleviate most problems?

[hsanjuan]

Another half-way solution would be to not keep permanent state but keep in-memory information of retries along with the operation objects. At least we could see how to persist the information at a later stage. We can combine this with pin-age prioritization too.