# Kocherga: inconsistency of AppUpdateInProgress state

**URL:** <https://forum.opencyphal.org/t/kocherga-inconsistency-of-appupdateinprogress-state/2435>\
**Category:** Applications & Usage\
**Created:** [January 9, 2026, 3:47pm UTC](https://forum.opencyphal.org/t/kocherga-inconsistency-of-appupdateinprogress-state/2435 "2026-01-09T15:47:20Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![ych](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/ych/32/1510_2.png) [@ych](https://forum.opencyphal.org/u/ych)\
**Post date:** [January 9, 2026, 3:47pm UTC](https://forum.opencyphal.org/t/kocherga-inconsistency-of-appupdateinprogress-state/2435/1 "2026-01-09T15:47:20Z")

</div>

From [State machine](https://github.com/Zubax/kocherga/blob/master/README.md#state-machine) description, `AppUpdateInProgress` state is indicated by:

- Node mode: `SOFTWARE_UPDATE`
- Node health: `NOMINAL`
- Vendor-specific status code: _number of read requests, always \>0_

However, in the [current implementation](https://github.com/Zubax/kocherga/blob/d806ba1dd6acb550aeeea7e21172fa08535a0213/kocherga/kocherga.hpp#L1210), the vendor-specific status code appears to be stored as `uint8_t` and incremented per read request. If the update image is larger than `64` KiB (or more generally if the number of read requests exceeds `255`), the counter will wrap and can become `0`, which breaks the “_always \> 0_” requirement from the README.

Is this wrap-around intended?

---

<div class="post-metadata">

**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\
**Post date:** [January 10, 2026, 10:10am UTC](https://forum.opencyphal.org/t/kocherga-inconsistency-of-appupdateinprogress-state/2435/2 "2026-01-10T10:10:34Z")

</div>

It’s a documentation shortcoming indeed. A pull request addressing it would be accepted. I couldn’t find any better use for the vendor-specific status code than showing the request count, but in Cyphal it is only 8-bits wide as you pointed out correctly (it used to be wider in UAVCAN v0 where this problem would not occur).