Improves panic message if send() fails in streaming_unpack_snapshot()

[brooksprumo]

Problem

There are reports on Discord¹² of people hitting panics while sending on a channel during snapshot unpacking. Here's an example:

thread 'solUnpkSnpsht01' panicked at /var/lib/buildkite-agent/builds/release/anza/agave-secondary/accounts-db/src/hardened_unpack.rs:338:45:
called `Result::unwrap()` on an `Err` value: "SendError(..)"
stack backtrace:

The unwrap doesn't yield the best panic message...

Summary of Changes

Improve the panic message.

Footnotes

1. https://discord.com/channels/428295358100013066/560174212967432193/1270412894026207305 ↩

2. https://discord.com/channels/428295358100013066/837340113067049050/1270052679309328408 ↩

[mergify]

Backports to the stable branch are to be avoided unless absolutely necessary for fixing bugs, security issues, and perf regressions. Changes intended for backport should be structured such that a minimum effective diff can be committed separately from any refactoring, plumbing, cleanup, etc that are not strictly necessary to achieve the goal. Any of the latter should go only into master and ride the normal stabilization schedule.

[mergify]

Backports to the beta branch are to be avoided unless absolutely necessary for fixing bugs, security issues, and perf regressions. Changes intended for backport should be structured such that a minimum effective diff can be committed separately from any refactoring, plumbing, cleanup, etc that are not strictly necessary to achieve the goal. Any of the latter should go only into master and ride the normal stabilization schedule. Exceptions include CI/metrics changes, CLI improvements and documentation updates on a case by case basis.

[steviez]

entry_path_buf instead of err.0.display right ?

[brooksprumo]

Yes, ish. The entry_path_buf was moved into the send, so we'd have to clone it. But conveniently, if send returns an Error, it puts the T back inside. So in our case here, err.0 is entry_path_buf and we don't need to clone it.

[steviez]

Oh nice, was not aware. And it looks like the Display impl for SendError does NOT print the T so we will not be double printing out the T.
https://docs.rs/crossbeam-channel/0.5.11/src/crossbeam_channel/err.rs.html#124-128

nit: Thoughts on using into_inner() over .0 ? I doubt crossbeam would be adding additional items (and reordering them) at this point, but I feel like into_inner() is slighter more expressive
https://docs.rs/crossbeam/latest/crossbeam/channel/struct.SendError.html#method.into_inner

[brooksprumo]

If we used into_inner(), would we lose the ability to log the error itself though?

[steviez]

Hmm yeah, I guess since we're inside a let Err(err) = ... block, we can't call into_innter() as that would move it. So, we'd have to clone; granted this isn't a big deal since the clone would be in the same line that we're panicking, but I think we can leave the .0 too