fix: avoid out of bounds error when rendering short hashes #8318
Conversation
|
I think the problem is slightly different. It looks like |
Stebalien
force-pushed
the
fix/path-panic
branch
from
8939fd4
to
39c76f8
Compare
|
Ah, I see. Yeah, that makes no sense. |
(caught higher up but should still be fixed)
Stebalien
force-pushed
the
fix/path-panic
branch
from
39c76f8
to
4742934
Compare
I believe we figured that these were for "informational purposes", but really, we _should_ always be able to resolve names to CIDs. If we can't, there's probably something wrong with the directory.
Stebalien
force-pushed
the
fix/path-panic
branch
from
4742934
to
66a76d2
Compare
|
I fixed it both ways. |
| resolved, err := i.api.ResolvePath(r.Context(), ipath.Join(resolvedPath, dirit.Name())) | ||
| if err != nil { | ||
| internalWebError(w, err) | ||
| return | ||
| } | ||
| hash := resolved.Cid().String() |
There was a problem hiding this comment.
@lidel what was the idea behind "Path may not be resolved. Continue anyways.", it seems like we should just fail here as this PR does?
There was a problem hiding this comment.
Also, how do we even reach the point where we error here? It seems like the UnixFS directory is telling us "here are the objects I have" and then we look for them and it errors.
There was a problem hiding this comment.
Also, how do we even reach the point where we error here? It seems like the UnixFS directory is telling us "here are the objects I have" and then we look for them and it errors.
Invalid sharded directory. Or a subshard of a sharded directory that we can list but can't traverse.
|
Ok, I'm going to merge this for now. We can change it later if there is a better fix. |
fix: avoid out of bounds error when rendering short hashes This commit was moved from ipfs/kubo@7c76118
The panic is caught higher up the stack so it can't crash the node, but it's still "not good".