attaching multiple effects in forRoot prevents any effects from running

[phra]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request

What is the current behavior?

if i add multiple effects in the effects module's forRoot, it stops from running every effects.

Expected behavior:

every registered effects works as expected.

Minimal reproduction of the problem with instructions:

EffectsModule.forRoot([Effect1]), // WORKS
EffectsModule.forRoot([Effect1, Effect2]), // DOES NOT WORK

if you specify more than one effect class, the effects' handlers are not called!

can be related to this line, maybe is the spread operator missing?

Version of affected browser(s),operating system(s), npm, node and ngrx:

latest

Other information:

single element array works, with two elements is not working.

[phra]

related to #232 ?

[phra]

i found how to stop this behaviour: in my case it depends on services being injected in Effect2 class..
EDIT: it seems caused by a circular dependency. i will refactor the flawed class this evening and i will leave a comment on the result. for sure this silent failure is very tricky to debug.

[phra]

i've finally found the issue. basically if you require a service in the effect class that is already included in the component it will silently crash. to proof this i've created two copies of the same service and renamed the type in order to have a new copy of it and i required it in the effect class' constructor. (yeah, it required a lot of debugging)

[brandonroberts]

If this is an ngrx issue, can you provide a reproduction of this issue? Preferably in a plunker or a github repo. Here is a plunker template http://plnkr.co/edit/tpl:757r6L?p=preview

[phra]

i've found the REAL issue. it was a timing bug. basically in the effect class i was injecting a service that in the constructor was dispatching the very first action so the effect class was instantiated AFTER the very first action being dispatched.
i can propose a quick solution to this: i suggest that if the action being dispatched is not catched by any effect or reducer, you should show at least a warning. (imho also an error can be correct, because if you are dispatching an action that is not being captured by anyone it's for sure an error or an useless action.)

@brandonroberts what do you think about this?

[MikeRyanDev]

While it would certainly improve the developer experience, there currently isn't a way for us to do introspection of reducer functions and know what actions they handle.

Glad you were able to track down the issue!

[phra]

@MikeRyanDev i got your point. i saw that every reducer is called on every actions and that is the switch() the is doing the filtering with the default case returning the current state.