Go-ipfs: Recursive IPNS resolve will not be performed if the LRU cache contains the record

[vasco-santos]

Version information:

go-ipfs version: 0.4.16-dev-2a9de81
Repo version: 7
System version: amd64/darwin
Golang version: go1.10.2

Type: Bug

Description:

While I was implementing my tests for IPNS in js-ipfs I found a bug with my implementation, which I believe that also happens in this implementation.

Basically, if I publish an ipfs hash followed by an ipns hash (pointing to the previous ipfs hash using a new key) and then, if I try to resolve the last one (ipns hash) with the recursive option enabled, it will hit the lur cache (if the record is still there) and it will not go with the recursive resolve.

[Stebalien]

So, looking into this, I'm pretty sure this isn't the case. We cache at the non-recursive resolver level and recurse at a higher layer.

That is, recursive resolution starts here:

https://github.com/ipfs/go-ipfs/blob/7e8f6c96047e1a94c1c892aa50e1c75e01b7fda2/namesys/namesys.go#L55-L65

Caching happens in the non-recursive resolver here:

https://github.com/ipfs/go-ipfs/blob/7e8f6c96047e1a94c1c892aa50e1c75e01b7fda2/namesys/namesys.go#L68-L108

And the recursive resolution logic is here:

https://github.com/ipfs/go-ipfs/blob/7e8f6c96047e1a94c1c892aa50e1c75e01b7fda2/namesys/base.go#L19-L56

---

Basically, the recursive resolver doesn't cache. Instead, it always asks the non-recursive resolver to resolve each step and the non-recursive resolver caches each step (independently).

Does this sound right?

[vasco-santos]

So, as far as I understand the flow is:

• go-ipfs/namesys/namesys.go: invoke resolve
• resolve has the recursive logic and invokes resolveOnce
• resolveOnce goes to cache and returns if available.

This way, I think you are right and this is correct. My implementation flow is a little different in this case. Thanks for your analyze @Stebalien 🙂