@clarrivey – glad you finally solved the problem. I can’t tell from reading the above whether you ran afoul of one of Snaplogic’s fundamental “gotchas”, but one that I’ve seen happen with our team here is the danger of thinking of snaps as individual program steps instead of programs themselves.
Interestingly enough, this is a trap that experienced programmers seem to fall into more often than “citizen implementors” who don’t have a formal programming background.
It helps me to think of each snap as a separate program, each of which can be running in parallel, and the connection between each pair of snaps is a queue. A pile of documents get spit out of a query snap or other data-producing snap, and they conceptually sit in a queue as the next snap processes each in sequence and puts the output docs one by one into the queue for the snap that follows. It is a true pipeline and there can be different docs found in different parts of the pipeline being processed simultaneously.
I’ve found this mental model to be particularly helpful in avoiding the “rat in the snake” problem (lots of data in one big glob that can only get through the pipeline one snap at a time, when there’s no need for it to do so). It also helps me to reason about decisions in the pipeline where it actually does need to wait on all the data to arrive so it can aggregate things.
Hope This Helps!
