Sysupgrade - pitfalls?

I reported issues regarding non-functional/partial sysupgrade already in the past, and encountered it again, using my custom built image (HEAD) for ZBT WE826, which includes some specialities: several additional packages (nginx, squid, php, openvpn ...), SD-Card used for swap and squid-cache.

Trying interactive sysupgrade (via wireless connection) fails silently again, which means, no visible error to show up, simply sysupgrade not done.

Now I also added
wifi down
into my script, which initiates sysupgrade after swapoff -a, umount /mnt/mmcblk0 etc.
and this seems to work, in case I also trigger my script for sysupgrade via LAN-connection.

Can anybody provide/confirm special requirements, for sysupgrade not to fail ?
'swapoff -a' ; killing all process with open files on block-device; seem to be part of these "special requirements", or pre-cautions, for sysupgrade not to fail .

As I also run sysupgrade on devices, which are remotely installed, flawless upgrade procedure is critical.

I have to mention, that sysupgrade was more reliable for me in the past, using 15.0.5

I see something similar with master, if swap is active and actually used, I see silent sysupgrade failures, that after the restart after the failed flash will go through (in that case swap typically is active but not used yet). I have not fully confirmed this observation so this is more anecdotal than scientific, but I believe I started to see this towards the end of last year...