Sometime, probably on Oct 31 04:00 UTC or after, I ingested the Oct 30 mbdump.edit.tar.bz2 and mbdump.editor.tar.bz2. So there is correlation with that ingestion and the replication failing. I don’t have evidence that the one caused the other.
That would be the issue, since MBImport.pl updates the replication_control table by default. So importing those would have rolled back the current_replication_sequence in that table. Now it’s trying to apply packets that have already been applied.
You might be able to find the point in your mirror.log where the replication sequence being downloaded jumps backwards rather than forward, and update the replication_control.current_replication_sequence column with the real sequence your database is at.
But the most straightforward option is dropping and recreating the database from scratch, making sure to pass --noupdate-replication-control to MBImport.pl when importing the edit/editor dumps next time.
If you can’t locate the correct sequence in mirror.log (edit: I missed the part where you said you’re missing contents from before Nov 1 UTC, so this sounds likely) and don’t want to re-import everything, but also don’t mind hacking a Perl file, a potential fast workaround may be to edit admin/replication/ProcessReplicationChanges inside the container, and initialize $ignore_conflicts to 1. That will just cause it to ignore any conflicting statements until you’re able to catch up to the correct packet again.