# Make commit\_unknown\_results unlikely - PR status

**URL:** <https://forums.foundationdb.org/t/make-commit-unknown-results-unlikely-pr-status/3413>\
**Category:** Development\
**Created:** [July 1, 2022, 12:26am UTC](https://forums.foundationdb.org/t/make-commit-unknown-results-unlikely-pr-status/3413 "2022-07-01T00:26:40Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**Author:** ![rajivr](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/rajivr/32/1100_2.png) [@rajivr](https://forums.foundationdb.org/u/rajivr)\
**Post date:** [July 11, 2022, 5:50am UTC](https://forums.foundationdb.org/t/make-commit-unknown-results-unlikely-pr-status/3413/7 "2022-07-11T05:50:31Z")

</div>

> [@andrew.noyes](#):
>
> A commit that fails with transaction\_timed\_out is _still in-flight_, so it could commit _after_ you read the sentinel key.

Thanks a lot for mentioning the issue with `transaction_timed_out`. I completely forgot about it! 🙂

You had also mentioned the following in a previous [thread](https://forums.foundationdb.org/t/how-are-you-testing-your-layers/3324/4).

> [@How are you testing your layers?](https://forums.foundationdb.org/t/how-are-you-testing-your-layers/3324/4):
>
> For `transaction_timed_out` this isn’t so bad, as the default retry loop (i.e. `on_error`) does not consider `transaction_timed_out` to be retryable. It does however consider `cluster_version_changed` to be retryable.

Are there any other [error codes](https://apple.github.io/foundationdb/api-error-codes.html) similar to `cluster_version_changed` that has the behavior of being retryable while the transaction is still in-flight?

In order to correctly deal with in-flight transactions for non-idempotent transactions, would the following mechanism work?

1. In the event we receive a `transaction_timed_out` or `cluster_version_changed`, wait for a specific duration of time, for example 10 seconds.

2. The in-flight transaction would have, by this time, either been committed, or the transaction would have been rejected due to the 5 second limit.

3. After 10 seconds, attempt to read the sentinel key again. This time if we are able to read the sentinel key, that would mean a successful commit. Missing sentinel key would mean the previous transaction failed to commit and would also not commit in the future.

> [@andrew.noyes](#):
>
> Also maybe I missed it but I don’t think the doc mentions what happens if the sentinel key could have been garbage-collected when you read it.

That would be an error in the garbage collection algorithm. For the design to work correctly, the garbage collection process must leave a threshold (for example: 72 hours) of sentinel keys untouched.

I’ve updated the document reflect this (Tracking is now enabled, so you can easily find the edit).

---

_[View the full topic](https://forums.foundationdb.org/t/make-commit-unknown-results-unlikely-pr-status/3413)._