[Google Pixel 8 Pro] badabing2003:
I respectfully disagree.

Let's break it down

Bullets 1 and 3 are correct, however that is not the argument, the argument is about bullet 2, and that also applies to full OTA (more on it below).

Copy-on-write ( COW ) , although it is utilized in partial OTA updates and not utilized with full OTA updates, is orthogonal to the primary concern of being able to roll back to active partition when update fails.

Copy-on-Write (COW) is a resource management technique used to efficiently manage and manipulate data. In the context of file systems, it refers to the method where if multiple callers request the same resource (such as a file or memory page), they are given pointers to the same resource, but with the stipulation that if any caller modifies the resource, a copy is made, and the modification is performed on the copy. This allows for efficient resource usage and helps in scenarios like snapshotting and versioning.

COW is an additional safety, which is good, but it is not the only safety.

Let's break down OTA update process and highlight the operational differences between the two and how is super (dynamic) partition updated differently.

Incidentrally, full OTA update is not limited to sideloading the package, your device receives full OTA updates (while running) when there is significant deviations from the expected system state. (Pixel July 2024 update being an example)

The update package is downloaded to the /data partition. (this applies to partial OTA and full OTA)

The package is verified for integrity and authenticity. (again no difference between partial OTA and full OTA)

With partial OTA, additional check is performed to make sure the current system state (the partition hashes) meet the exact expectations (the before state) to successfully perfrorm partial update, this is the main reason why partial OTA updates fail and are rolled back on rooted systems and why you need to unrooot first.

On the other hand full OTA updates doesn't care about the previous state, and can be applied unconditionally, which is the main reason why people get surprised that their system was updated while they were rooted, and effectively lost root, (the naiive expectation being that OTA updates don't work while rooted).

With modern A/B devices, there is one super partition that contains dynamic logical partitions.

Logical partitions within super (e.g., system_a, system_b, vendor_a, vendor_b, etc.) follow the A/B scheme.

Partial OTA (incremental OTA) apply changes directly to the existing inactive partitions within the super partition using Copy-on-Write mechanism you mentioned while the system is running.

Only the differences (deltas) between the current state and the new update are applied.

During a full OTA (Over-The-Air) update on devices that utilize A/B partition schemes, the update process typically modifies the super partition and updates the inactive partitions within it after reboot, not while the system is running.

The device reboots into recovery mode, and the update process updates just the inactive partitions within the super partition, and of course this updating process typically includes writing the entire contents of the updated partitions. Active partition are left intact.

Post-Write steps: (irrelevant for this discussion, as it's the same for partial and full OTA updates)

After all partitions are written, the device prepares to switch slots.

Metadata in the bootloader is updated to mark the new slot as bootable.

The device reboots into the updated inactive slot, making it the new active slot.

A post-installation script might run to finalize the update.

If the update is successful, the device continues to run from the new slot.

If the update fails, the device will revert to the previous slot.

Note: The main difference between performing an OTA update while the system is running and sideloading an OTA update lies in the method of delivering and applying the update.

With full OTA update (occuring in recovery mode), generally, the active partition within the super partition is protected during the update process. The update mechanism ensures that the active partition continues to function normally.

However, if the update process fails catastrophically (such as due to power loss or severe hardware failure), there is a theoretical risk that the interruption could cause some form of data corruption or instability on the active partition. This risk is generally minimized by design, as update mechanisms typically involve safeguards to prevent such occurrences.

This theoretical risk mitigation with COW is the only additional benefit you're getting from partial OTA updates, as Copy-on-Write has a rollback functionality.

This is incorrect

The exact reason why full OTA is safer than factory image.

Factory image is flashed into active slot, and if the update is not complete or something goes wrong, the device cannot boot to system. This is a certainty.

If you suggest that the factory image could be flashed to inactive slot and if anything goes wrong, one can still boot back to a functional (assumed) active slot effectively making factory image behavior similar to full OTA. This is incorrect, because by simply flashing a factory image to inactive slot, you're breaking the active slot's system partition, see here why this is the case.

To be able to perfom the dd operation, you need to be rooted, and if you're rooted, then dumping the init_boot would not be the stock init_boot, it will be the patched init_boot.

You need to use the stock backup made by Magisk (assuming that the backup was successful at the time of patching).