Jeff

one of the prime directives of the content migrator is security. Since content migration happens between servers, having a push to functionality would allow anyone with access to an environment...

I looked into doing that a few years ago and determined it wasn't worth it. I forget why, i'll check again.

looking at the stack trace, I'd guess it happens in the rare occurrence of the pipeline running without a valid context database. It's certainly not a serious problem, but should...

this one is an interesting one. The system works that threads don't get seeded unless the parent item is already installed, so outside of having an error occur it shouldn't...

for reference, there is some code built to protect this kind of child before the parent install scenario [seen here](https://github.com/JeffDarchuk/SitecoreSidekick/blob/master/ContentMigrator/Core/ContentItemInstaller.cs#L319)

itemsToInstall is a BlockingCollection. If the collection is empty and the thread adding things to the BlockingCollection hasn't switched the `CompleteAdding` flag it'll thread sleep until an item is added...

yeah, that would be a good test. Additionally if your situation has anything notable about it that might help me reproduce this, please share.

Under the hood for comparison purposes it uses Unicorn's Rainbow library to do the comparison. It's the same thing that Unicorn uses to validate when an item should be updated...

People have reported errors similar to this related to the Item Blaster support. Does it work correctly if you only run the operation without Item Blaster?

Ah, unfortunately it's a common problem that some people have. In future versions I'm planning to have it disabled by default and have the main use case for item blaster...