Usually, if the option is available, installing a new update semi-manually is easier than EDL-ing individual partitions.
Especially since super has become multiple files on some devices.
You can try adb sideload (I never have).
If that doesn't work, we can try the flash drive method.
That works with update-binary, but I've never tried with this new update engine.
Code:
update_engine_client --help
Android Update Engine Client
--allocate (Given payload metadata, allocate space.) type: bool default: false
--cancel (Cancel the ongoing update and exit.) type: bool default: false
--follow (Follow status update changes until a final state is reached. Exit status is 0 if the update succeeded, and 1 otherwise.) type: bool default: false
--headers (A list of key-value pairs, one element of the list per line. Used when --update or --allocate is passed.) type: string default: ""
--help (Show this help message) type: bool default: false
--merge (Wait for previous update to merge. Only available after rebooting to new slot.) type: bool default: false
--metadata (The path to the update payload metadata. Used when --verify or --allocate is passed.) type: string default: "/data/ota_package/metadata"
--offset (The offset in the payload where the CrAU update starts. Used when --update is passed.) type: int64 default: 0
--payload (The URI to the update payload to use.) type: string default: "http://127.0.0.1:8080/payload"
--reset_status (Reset an already applied update and exit.) type: bool default: false
--resume (Resume a suspended update.) type: bool default: false
--size (The size of the CrAU part of the payload. If 0 is passed, it will be autodetected. Used when --update is passed.) type: int64 default: 0
--suspend (Suspend an ongoing update and exit.) type: bool default: false
--update (Start a new update, if no update in progress.) type: bool default: false
--verify (Given payload metadata, verify if the payload is applicable.) type: bool default: false