Fork me on GitHub
#onyx
<
2016-01-19
>
jimmy02:01:37

congrats on the new release simple_smile

robert-stuttaford04:01:57

great work @michaeldrogalis and @lucasbradstreet! this happens to be perfectly timed for us - we’re going multi-instance in the next couple weeks simple_smile

lucasbradstreet04:01:08

@robert-stuttaford: it should definitely help ensure the perf impact of going multi-node is smaller :)

lucasbradstreet11:01:05

thanks. Looks like the cheat sheet path also changed: http://www.onyxplatform.org/docs/cheat-sheet/

lucasbradstreet11:01:33

I’ll get a redirect going. I don’t want to lose all the links we’ve picked up

robert-stuttaford11:01:41

how’s married life? simple_smile

robert-stuttaford11:01:04

you fighting over who gets to hold the TV remote, yet? 😁

lucasbradstreet12:01:35

It's much the same, ha

lucasbradstreet12:01:47

But it's good. I keep forgetting to wear the ring though :p

michaeldrogalis15:01:29

Thanks everyone!

greywolve16:01:38

question about flow conditions that catch exceptions, do they only regulate flow when an exception is thrown? i.e if i have a workflow from a -> b, and I put a flow condition from a to b that catches exceptions, does that mean, when an exception isn't thrown, that segments still flow from a -> b ?

lucasbradstreet16:01:14

The docs could be a little clearer there. I believe if it doesn't short circuit because an exception was thrown it'll just use the default behaviour, which is to flow to all outgoing tasks

lucasbradstreet16:01:33

@greywolve: if you want to control the behaviour there you can add a later flow condition

greywolve16:01:18

thanks lucas simple_smile

greywolve16:01:58

and i'm assuming flow conditions only apply to their to and from ? if i have a -> b, and a -> c, and i only have one flow condition, which restricts a going to b with a certain predicate, i'm presuming a still flows to c?

greywolve16:01:12

i'll be happy to edit the docs for more clarity once i properly got my head around them simple_smile

lucasbradstreet16:01:46

Yes, I believe that is the case

lucasbradstreet16:01:25

It's easier to compose conditions together for the same task as a result

lucasbradstreet17:01:28

I recommend having a look at some of the tests sometimes when you have some questions about the features. They’re usually pretty straight forward integration tests under test/onyx/peer

lucasbradstreet17:01:54

We definitely appreciate hearing when the docs are a bit confusing though

greywolve17:01:47

great, thanks again, think i'm clear now

greywolve18:01:32

@lucasbradstreet: I modified the flow combine example to test the a -> b, a -> c case above, it seems that if you only have one flow condition, say a -> b, then for a -> c, a never flows to c.

greywolve18:01:49

just wondering if that's intended behaviour, and if we can rely on that staying the same?

greywolve18:01:56

in the file above i have a -> out, and a -> b, testing a single flow condition active for each. when both flow conditions are there you see the output for both tasks, when one only flow condition is there you only see output for one of the tasks, which would imply that if you do have a flow condition you need to make sure all your out going edges are covered by them, any out going edges you forget, won't be flowed to?

lucasbradstreet18:01:35

@greywolve: ah, you may be right about that

michaeldrogalis18:01:16

@greywolve: That is the intended behavior. You can think of it like a pattern matcher, where you can :flow/to -> :all if you want to catch all.

lucasbradstreet18:01:59

Sorry, I always forget how it works. But yeah, all the matching flow/to tasks are unioned unless you use short circuiting.

greywolve18:01:59

great, makes sense simple_smile

greywolve18:01:58

no worries, i was just baffled by how our one job was doing the right thing, so kept digging. now it all makes sense, haha