Doesn't look like it, no :reduce in the source that I can find, and definitely letting all segments through.

Yeah, you’re right. It’ll need a bit of a refactoring to separate out the transformed segments from the triggered segments so that when we pass the segments downstream we can correctly identify which ones we want to pass down based on the onyx/type.

Actually it might be enough to just decide in here https://github.com/onyx-platform/onyx-local-rt/blob/0.12.x/src/onyx_local_rt/impl.cljc#L276 since onyx.core/triggered has all of the triggered segments. We need to bring it closer in line with what is in onyx core though.

Hey everyone - I’m writing a pretty straightforward output plugin, and I have a few questions about making network calls asynchronously The output has to make calls that are potentially very long-running (~30 seconds if it times out/errs), but I don’t want that to hold up other calls being made (esp. if the batch size is more than a few), since the results of the calls aren’t related to each other. I originally wrote it using pmap to execute them all in parallel, but I’m wondering if there’s a better way to handle that that will work better with the framework (and since I don’t see pmap being using in the other plugins I’ve checked out). I set up a test environment using the flat-workflow example in examples repo, and obviously changing pmap to map causes the calls to be executed one at a time, which I’d like to avoid

Hi @gseyffert, I have some comments for you, but I’ll have to get back to you on it.

Take your time!