After speaking with Dave a bit, there are a few points that I think I'm
trying to address, all of which are roughly tied together.
I think the point now is to figure out which of the following need to be
broken out as tickets, which (if any) are bugs that should be fixed, and
which require more
Chris:
Agreed, it would be nice if the iterators were designed to handle their own
exceptions, and that is certainly the case for this particular iterator.
Dave:
The behavior does seem to indicate that the failure is not being propagated
back up. The transactions are never marked as failed. The
I think FaTE ensures that the transaction is started and it waits for it to
finish. It must be the case that a failure is not being propagated back up
to fail the transaction. Are you seeing FaTE restarting the same compaction
over and over again, or are the multiple IN_PROGRESS transactions from
The behavior in case of error is likely undefined, so I'm not entirely
surprised it's behaving this way. There may be things we can do to try to
handle errors more gracefully for user initiated compactions when an
iterator throws an exception, but it's definitely a good idea to write
custom
Thanks Chris for the quick reply. I'll explain the behavior I'm seeing, and
then maybe you all could either confirm this is the intended behavior, or
decide it's maybe not that great.
My understanding of the happy case for running a user-initiated compaction
is that a fate/transaction gets
Yes, either here (especially if it's related to a bug or proposed code
change) or at user@ would work, if it's more of a user question. Here is
fine if you're not sure.
On Wed, Jul 6, 2022, 16:35 Logan Jones wrote:
> Hello:
>
> I would like to discuss what happens when iterators cause
Hello:
I would like to discuss what happens when iterators cause user-initiated
compactions to fail, specifically in relation to the fate transactions. Is
this the right list for this discussion?
Thanks,
- Logan
