wrappedIterator.next is not a function

[ssynix]

I have the following setup in my code. My problem is that the sagas inside sagaCallee were not intercepted by my providers. However, for some reason I can't even make this simple example work because it fails with:

uncaught at saga at sagaWrapper at delay TypeError: wrappedIterator.next is not a function

I assume I'm missing something obvious here, but can't seem to figure out what.

it('should succeed', () => {
    return expectSaga(saga)
        .provide([
            [select(selector), 'provided'],
        ])
        .run();
});

const selector = (state) => { throw Error("I shouldn't be called"); };

function* sagaCaller(someSaga) {
    let throttler;
    // In the actual code, this is executed in a loop to ensure that `someSaga` is called at most every 50 ms
    try {
        throttler = yield fork(delay, 50);
        yield fork(someSaga);
    } finally {
        yield join(throttler);
    }
}

function* saga() {
    yield call(sagaCaller, function* sagaCallee() {
        yield select(selector);
    });
}

[ssynix]

Not sure if somehow related to https://github.com/jfairbank/redux-saga-test-plan/issues/140. Ran into both issues while working on the same test.

[jfairbank]

Hi, @ssynix!

Is delay a regular function or a generator function? Redux Saga Test Plan expects only generator functions to be forked, so I'm guessing that delay is a regular function and it's failing here:

throttler = yield fork(delay, 50);

Is there any reason why you can't do something like this instead?

function* sagaCaller(someSaga) {
    // In the actual code, this is executed in a loop to ensure that `someSaga` is called at most every 50 ms
    yield fork(someSaga);
    yield call(delay, 50);
}

If this is getting called by takeEvery like you suggest in #140, you could also look at throttle.

[ssynix]

delay is provided by redux-saga, which is an async function.

There's other work before calling someSaga that can take some time to finish and can throw exceptions, but it might still be possible to refactor that logic into something closer to your proposed sagaCaller. It's still unusual though that code that runs successfully using redux-saga fails with hard to decipher errors using redux-saga-test-plan. redux-saga does mention that both fork and call can accept generators or promises.

I'm not sure if throttle does exactly what I want to do, but I can take another look at it!

---

More background: the code that I'm testing here (and in #140) is trying to listen on subscription actions and for each of them (takeEvery), grab some extra info from the state (select) and subscribe to that feed. Subscribing to a feed involves calling an API at an interval (which can take greater/less than the interval duration, and can throw errors). The result is a series of dispatched success/failed actions per feed at a rate at least as slow as the interval.

PS. thanks for the great library! Definitely takes saga testing to a new level.

[sbaechler]

@jfairbank I ran into the same issue. Redux-Saga allows any function that return a promise to be forked. Is this going to be supported in a future version?

[maleetz]

While I agree it would be nice to include this in a future version, it is simple enough to workaround with a macthers.fork.fn call in the provider list, which prevents redux-saga-test-plan from trying to execute the regular function as a generator function.