"AssertionError len(chain_list) == 2" after completing a full backup, unable to do incremental

[Artur Bodera]

duplicity 0.7.04 (August 02, 2015)
/usr/local/opt/python/bin/python2.7 2.7.10 (default, Jul 13 2015, 12:05:58)
[GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)]

Upon finishing a multi-day, initial, full backup, i've received the following at the very end:
---------------------
Traceback (most recent call last):
  File "/usr/local/Cellar/duplicity/0.7.04_1/libexec/bin/duplicity", line 1528, in <module>
    with_tempdir(main)
  File "/usr/local/Cellar/duplicity/0.7.04_1/libexec/bin/duplicity", line 1522, in with_tempdir
    fn()
  File "/usr/local/Cellar/duplicity/0.7.04_1/libexec/bin/duplicity", line 1376, in main
    do_backup(action)
  File "/usr/local/Cellar/duplicity/0.7.04_1/libexec/bin/duplicity", line 1401, in do_backup
    globals.archive_dir).set_values()
  File "/usr/local/Cellar/duplicity/0.7.04_1/libexec/lib/python2.7/site-packages/duplicity/collections.py", line 721, in set_values
    backup_chains)
  File "/usr/local/Cellar/duplicity/0.7.04_1/libexec/lib/python2.7/site-packages/duplicity/collections.py", line 734, in set_matched_chain_pair
    sig_chains = sig_chains and self.get_sorted_chains(sig_chains)
  File "/usr/local/Cellar/duplicity/0.7.04_1/libexec/lib/python2.7/site-packages/duplicity/collections.py", line 951, in get_sorted_chains
    assert len(chain_list) == 2
AssertionError
----------------------

I am unable to start another incremental, because the error keeps appearing every time.

My local and remote meta are synchronized:
----------
l ~/.cache/duplicity/backup-name
total 24810848
drwxr-xr-x 6 Thinkscape staff 204B Sep 26 11:17 .
drwxr-xr-x 7 Thinkscape staff 238B Sep 20 13:40 ..
-rw-r--r-- 1 Thinkscape staff 5.0G Sep 26 11:12 duplicity-full-signatures.20150920T135054Z.sigtar.gpg.1.gz
-rw-r--r-- 1 Thinkscape staff 933M Sep 26 11:17 duplicity-full-signatures.20150920T135054Z.sigtar.gpg.2.gz
-rw------- 1 Thinkscape staff 5.9G Sep 26 04:37 duplicity-full-signatures.20150920T135054Z.sigtar.gz
-rw------- 1 Thinkscape staff 8.4M Sep 26 04:37 duplicity-full.20150920T135054Z.manifest
-----------

Here's incremental attempt (paths and names obfuscated):
--------------------
Mode not provided - assuming incremental
Using archive dir: dir
Using backup name: backup-name
Import of duplicity.backends.azurebackend Succeeded
Import of duplicity.backends.botobackend Succeeded
Import of duplicity.backends.cfbackend Succeeded
Import of duplicity.backends.copycombackend Succeeded
Import of duplicity.backends.dpbxbackend Succeeded
Import of duplicity.backends.gdocsbackend Succeeded
Import of duplicity.backends.giobackend Succeeded
Import of duplicity.backends.hsibackend Succeeded
Import of duplicity.backends.hubicbackend Succeeded
Import of duplicity.backends.imapbackend Succeeded
Import of duplicity.backends.lftpbackend Succeeded
Import of duplicity.backends.localbackend Succeeded
Import of duplicity.backends.megabackend Succeeded
Import of duplicity.backends.multibackend Succeeded
Import of duplicity.backends.ncftpbackend Succeeded
Import of duplicity.backends.onedrivebackend Succeeded
Import of duplicity.backends.par2backend Succeeded
Import of duplicity.backends.pydrivebackend Succeeded
Import of duplicity.backends.rsyncbackend Succeeded
Import of duplicity.backends.ssh_paramiko_backend Succeeded
Import of duplicity.backends.ssh_pexpect_backend Succeeded
Import of duplicity.backends.swiftbackend Succeeded
Import of duplicity.backends.sxbackend Succeeded
Import of duplicity.backends.tahoebackend Succeeded
Import of duplicity.backends.webdavbackend Succeeded
Main action: inc
================================================================================
duplicity 0.7.04 (August 02, 2015)
Args: /usr/local/Cellar/duplicity/0.7.04_1/libexec/bin/duplicity incremental --asynchronous-upload --verbosity info --name backup-name --encrypt-key AAAAAAAAA --volsize 256 --exclude /path/*.sparsebundle --log-file /var/log/duplicity.log /path cf+hubic://backup
Darwin Taco.local 14.5.0 Darwin Kernel Version 14.5.0: Wed Jul 29 02:26:53 PDT 2015; root:xnu-2782.40.9~1/RELEASE_X86_64 x86_64 i386
/usr/local/opt/python/bin/python2.7 2.7.10 (default, Jul 13 2015, 12:05:58)
[GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)]
================================================================================
Using temporary directory /var/folders/sn/lw4b5p6s6793ghngffqsy8cc0000gn/T/duplicity-_YiLnY-tempdir
Temp has 188218208256 available, backup will use approx 617401548.
Local and Remote metadata are synchronized, no sync needed.
Traceback (most recent call last):
  File "/usr/local/Cellar/duplicity/0.7.04_1/libexec/bin/duplicity", line 1528, in <module>
    with_tempdir(main)
  File "/usr/local/Cellar/duplicity/0.7.04_1/libexec/bin/duplicity", line 1522, in with_tempdir
    fn()
  File "/usr/local/Cellar/duplicity/0.7.04_1/libexec/bin/duplicity", line 1376, in main
    do_backup(action)
  File "/usr/local/Cellar/duplicity/0.7.04_1/libexec/bin/duplicity", line 1401, in do_backup
    globals.archive_dir).set_values()
  File "/usr/local/Cellar/duplicity/0.7.04_1/libexec/lib/python2.7/site-packages/duplicity/collections.py", line 721, in set_values
    backup_chains)
  File "/usr/local/Cellar/duplicity/0.7.04_1/libexec/lib/python2.7/site-packages/duplicity/collections.py", line 734, in set_matched_chain_pair
    sig_chains = sig_chains and self.get_sorted_chains(sig_chains)
  File "/usr/local/Cellar/duplicity/0.7.04_1/libexec/lib/python2.7/site-packages/duplicity/collections.py", line 951, in get_sorted_chains
    assert len(chain_list) == 2
AssertionError
----------------

Please help.

[Kenneth Loafman (kenneth-loafman)]

Please run an incremental backup, but this time use "--verbosity debug" instead of "--verbosity info". Munge any personal info in the log, but keep the format identical.

Did you have any interruptions during the long backup?

[Tenzing (mat-5)]

I have the same bug with duplicity 0.7.17 (current stable) using the cf+hubic target, also happening on very long backups that take about a week to run. Shorter backups are doing fine.

In my case though it's the initial full backup that fails, with this similar traceback:

Local and Remote metadata are synchronized, no sync needed.
ionice: ignoring given class data for idle class
Traceback (innermost last):
  File "/opt/duplicity-0.7.17/bin/duplicity", line 1555, in <module>
    with_tempdir(main)
  File "/opt/duplicity-0.7.17/bin/duplicity", line 1541, in with_tempdir
    fn()
  File "/opt/duplicity-0.7.17/bin/duplicity", line 1393, in main
    do_backup(action)
  File "/opt/duplicity-0.7.17/bin/duplicity", line 1419, in do_backup
    action).set_values()
  File "/opt/duplicity-0.7.17/local/lib/python2.7/site-packages/duplicity/collections.py", line 722, in set_values
    backup_chains)
  File "/opt/duplicity-0.7.17/local/lib/python2.7/site-packages/duplicity/collections.py", line 735, in set_matched_chain_pair
    sig_chains = sig_chains and self.get_sorted_chains(sig_chains)
  File "/opt/duplicity-0.7.17/local/lib/python2.7/site-packages/duplicity/collections.py", line 955, in get_sorted_chains
    assert len(chain_list) == 2
AssertionError

[Tenzing (mat-5)]

In my case the backup was interrupted and restarted quite a few times, like 10 to 15 times, because of problems at the remote host (500, etc.).

[Tenzing (mat-5)]

Alright, so this bug happens quite often to me when doing large backups (multiple TB) that often get interrupted and retried. Here's a workaround that seems to work:

* locate the bad files: "duplicity collection-status -v9 $target_url | grep 'rejected by backup set'"
* remove the bad files on the remote end.