upgrade-juju fails on all providers

I'm wondering if your script is detecting the right thing, looking at this console output:
http://ec2-54-84-137-170.compute-1.amazonaws.com:8080/job/hp-upgrade/1089/console

During the last upgrade it gets to:
juju --show-log upgrade-juju -e test-release-hp --version 1.19.1
...
+ PATH=/mnt/jenkinshome/jobs/hp-upgrade/workspace/extracted-bin/usr/lib/juju-1.19.1/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin
+ /var/lib/jenkins/ci-cd-scripts2/wait_for_agent_update.py test-release-hp
1.18.1: 1, 0, 2, dummy-sink/0, dummy-source/0
1.18.1: 1, 0, 2, dummy-sink/0, dummy-source/0
1.18.1: 1, 0, 2, dummy-sink/0, dummy-source/0
1.18.1: 1, 0, 2, dummy-sink/0, dummy-source/0
1.18.1: 1, 0, 2, dummy-sink/0, dummy-source/0
1.18.1: 1, 0, 2, dummy-sink/0, dummy-source/0
1.18.1: 0, dummy-sink/0, dummy-source/0
1.18.1: 0, dummy-sink/0, dummy-source/0
1.18.1: 0, dummy-sink/0, dummy-source/0
1.18.1: 0, dummy-sink/0, dummy-source/0
1.18.1: 0, dummy-sink/0, dummy-source/0
1.18.1: 0, dummy-sink/0, dummy-source/0
1.18.1: 0
1.18.1: 0
1.18.1: 0
1.18.1: 0

I was misunderstanding the output. It isn't that 0 items haven't upgrade, but instead that the agent calling itself '0' (aka machine agent for machine-0) is still on 1.18.1. That is really strange. It does seem to fit what I'm seeing in the log files, though. What is weird is that I see several machines upgrade (they at least stop being 1.18.1, perhaps they are just dead. It might be useful to have slightly different output here.)

I haven't been able to reproduce this (upgrade succeeds in the various tests that I've tried locally and on AWS), but I'll keep poking at it.

lp:juju-core r2655 fixed upgrade. I don't see a reason why this rev fixed the issue. Nate and I thought lp:juju-core r2654 was the more likely reason, but test results show that all upgrades failed with the earlier rev.