Maybe there should be a way for pin rm command not to throw an error when object is not pinned

[mitar]

Otherwise currently user has first to check if object is pinned, if they just try to forget about an object fully.

[mitar]

Also, if I run a pin rm command with multiple hashes and one of them is not pinned, command still returns an error and it is unclear what is the state. Did it apply partially? Fully except for not pinned? Not at all?

[daviddias]

@whyrusleeping wanna chime in on this one?

[daviddias]

@whyrusleeping ping

[whyrusleeping]

Yeah, that would be nice to have. Any proposals of what that should look like?

[Kubuxu]

I am not sure about it. I am not sure how js API is structured but recovering from an error shouldn't be hard.

[daviddias]

@whyrusleeping what about a ndjson stream with an object per hash unpinned and a bool telling if it was successful or not?

@Kubuxu it is not about recovering from an error, it is just simply not knowing what happened.

[Stebalien]

There's a PR for go-ipfs (ipfs/kubo#5843) and an issue (ipfs/kubo#5716).

The current proposal is to add an "Error" map to the output mapping pins we failed to remove to error messages. That is: {"Pins": [ ... ], "Error": {"Qm...": "pin not found"}}.

Questions:

• Thoughts on this output type?
• Should we require a --force flag to enable this behavior?
• Should we enable this behavior by default but return a final real (commands library level) error after the result (unless a --force flag is specified)?

[alanshaw]

@whyrusleeping what about a ndjson stream with an object per hash unpinned and a bool telling if it was successful or not?

I think this ^ was a good idea and would solve the issue of communicating what has/hasn't been unpinned without bailing. It would allow us to unpin big directories without running out of memory as well as giving the user feedback quickly when the unpin takes a long time.

---

To attempt to answer your questions:

• Thoughts on this output type?

IMHO if people want to ignore CIDs that aren't pinned then they won't care specifically which CIDs were not pinned. I don't think the output needs to change.

• Should we require a --force flag to enable this behavior?

I think it should just be the default behaviour to ignore CIDs that aren't pinned and have the current behaviour if the user passes a different flag.

What about --ignore-non-pins which is default true?

That said, --force + Errors: { QmHash: "not found" } is a convenient non-breaking solution. So if you decide to go with it then I'm ok with it. Is there errors other than "pin not found"? If no then why not add NonPins: [ ... ] to the response instead?

• Should we enable this behavior by default but return a final real (commands library level) error after the result (unless a --force flag is specified)?

That is tricky from a JS standpoint, it's very unusual for callbacks to be called with both an error and a result and it cannot be done with promises. If we wanted to do that, the result would have to include the error.

So yes, IMHO it should be default, but --ignore-non-pins=false would exhibit the current behaviour - it's breaking but the upgrade path is easy.

---

To summarise, my preferences in decreasing popularity:

1. break it completely and go with @daviddias's solution 💥 🚀
2. change default behaviour to ignore non-pins, add --ignore-non-pins=[true] (--ignore-non-pins=false exhibts current behaviour), add NonPins: [ ... ] to output when ignoring (optionally - I don't think it's needed)
3. do not change default behaviour, add --force and add NonPins: [ ... ] to output when forcing
4. do not change default behaviour, add --force and add Error: { QmHash: "pin not found" } to output when forcing