Hello,
I have a question regarding the internal handling of the update recovery process for BLE mesh DFU, specifically within the DFU Server model + BLOB Server model.
I know there's support for a target to recover if it gets rebooted in the middle of an update, and that on the user's end, the transfer recovery callback must be defined and must provide a valid BLOB stream for the server model. But is the write address for the next received chunk automatically stored and restored with the rest of the transfer state so that, upon reboot + recovery, the transfer process can automatically resume at the correct starting location? Or is this something that I'll need to manage in my application? I tried to work it out by looking through the source code and saw that both the DFU Server and the BLOB Server models use their own "store_state" function regularly throughout the transfer process, but it's not immediately clear to me if the write address is part of the stored state.
I ask because I'm providing the BLOB stream in the transfer recovery callback using bt_mesh_blob_io_flash_init(), which takes a parameter representing the "offset into the flash area, in bytes". But after a reboot, I don't have direct access to this offset.
Please let me know if any additional information is needed! Thank you!
