fix: getting deleted blobs should return error

[Frando]

Description

Right now there is a bug in the store: When you delete a blob by deleting its tag, run gc, and then do store.get_bytes(hash), it will not return an error but instead an emtpy byte slice (b""). This, of course, is very wrong: we should never return data that doesn't match the requested hash.

This PR fixes the logic to not create empty blobs on-demand when running get or export operations.

Also adds a test that ensures that, for deleted blobs, errors are returned for get_bytes, export, export_bao, export_ranges for both the fs and mem store.

Additionally, I noticed that Blobs::delete and delete_with_opts is not actually usable as a public API because there's internal protections of hashes that make it not work as intended (it is only used from gc, where protections are cleared before). Therefore I made the function non-public to not confuse users.

Breaking Changes

• iroh_blobs::api::blobs::Blobs::delete and delete_with_opts are no longer public. These functions did not actually delete blobs, because blobs would usually be protected. The function is now only used internally during garbage collection (where protections are cleared beforehand in a non-public way). Public users can only use garbage collection for deletion of blobs.

Notes & open questions

Change checklist

• Self-review.
• Documentation updates following the style guide, if relevant.
• Tests if relevant.
• All breaking changes documented.

[github-actions]

Documentation for this PR has been generated and is available at: https://n0-computer.github.io/iroh-blobs/pr/95/docs/iroh_blobs/

Last updated: 2025-07-03T10:37:47Z

[Frando]

My changes in this commit ea29863 made other tests fail. To make them pass again, I pushed this commit dd59017.

It does this:

• Add an option for export_bao to optionally create the entry if it doesn't exist
• Port the special-case handling for Hash::EMPTY from the fs store to the mem store

With these two changes, all tests pass again.

Not too sure about the special casing of the empty hash - I'd have to dive in deeper to analyze this, but seems fine because the fs store does it too?

[rklaehn]

This is quite an embarrassing bug. Thanks for finding this first.

I don't think the create_if_missing parameter is useful. I removed it again and instead handled the error in the code where it computes local data for a HashSeq. WDYT?

[rklaehn]

Not too sure about the special casing of the empty hash - I'd have to dive in deeper to analyze this, but seems fine because the fs store does it too?

The empty hash is weird. Also, I don't want to remember whether I have the empty hash or not, and it costs nothing to always have it. That's the reason for the special case.