feat: beatree propagates errors during begin_sync #772
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
gabriele-0201
force-pushed
the
gm_handle_errors_beatree_sync
branch
3 times, most recently
from
380ff15 to
961bf0e
Compare
There was a problem hiding this comment.
I find this change a tad bit convoluted!
Just consider this. We wrap begin_sync_task in catch_unwind which returns thread::Result. Then we stringify/type-erase it via anyhow. Then we coerce that into std::io::Result with the ErrorKind::Other! In this context, IMO, every use of Other should be scrutinized.
Let's unwind this spaghetti (🥁).
We can pass the panic payload through the channel and then on the receiving side perform panic::resume_unwind(payload).
One thing is that I am not sure what will get printed upon propagating this panic. I am pretty sure the backtrace printed will originate from resume_unwind which is useless and the one in catch_unwind is way more valuable.
gabriele-0201
force-pushed
the
gm_handle_errors_beatree_sync
branch
from
961bf0e to
faf1d6b
Compare
There was a problem hiding this comment.
The new version shapes up way better. Also want to highlight that nomt/src/beatree/allocator/mod.rs got std::io::Result on some of its functions, specifically allocate and grow, just because I tripped on that a couple of times already.
Requires fixing up the tests.
gabriele-0201
force-pushed
the
gm_handle_errors_beatree_sync
branch
from
faf1d6b to
3f963ce
Compare
gabriele-0201
force-pushed
the
gm_add_task_result
branch
from
88f0f7b to
a480fe1
Compare
gabriele-0201
force-pushed
the
gm_handle_errors_beatree_sync
branch
from
3f963ce to
17033d0
Compare
|
tests fixed! |
pepyakin
changed the base branch from
gm_add_task_result
to
graphite-base/772
pepyakin
force-pushed
the
gm_handle_errors_beatree_sync
branch
from
17033d0 to
b19d214
Compare
No description provided.