pEvent does not reliably return when used on same key twice

[jwalton]

I'm trying to use p-event in a test case. I have a key-value implementation which is watching a key. There should be a 'change' event fired when I create the watch, and then a second event fired if the key changes:

import * as promiseTools from 'promise-tools';
import pEvent from 'p-event';

        it('should watch a key', async function() {
            const stub = sinon.stub();

            await kv.setKey('foo', { foo: 1 });

            const watch = kv.watchKey('foo');
            watch.on('change', stub);

            await promiseTools.whilst(() => stub.callCount !== 1, () => promiseTools.delay(100));

            await kv.setKey('foo', { foo: 2 });

            await promiseTools.whilst(() => stub.callCount !== 2, () => promiseTools.delay(100));

            sinon.assert.calledTwice(stub);
            sinon.assert.calledWith(stub, { watch, key: 'foo', value: { foo: 1 } });
            sinon.assert.calledWith(stub, { watch, key: 'foo', value: { foo: 2 } });
        });

        it('should watch a key', async function() {
            await kv.setKey('foo2', { foo: 1 });

            const watch = kv.watchKey('foo2');
            const e1 = await pEvent(watch, 'change');
            expect(e1).to.eql({watch, key: 'foo2', value: {foo: 1}});

            await kv.setKey('foo', { foo: 2 });

            console.log('here');
            const e2 = await pEvent(watch, 'change');
            expect(e2).to.eql({watch, key: 'foo2', value: {foo: 2}});
        });

These two test cases ought to be equivalent, but the first one passes reliably, and the second one prints "here" and then times out waiting for the second await (but passes rarely). Am I missing something here?

[kevva]

You need to attach the event listener before the event is emitted. If the change event is emitted upon creating watch and pEvent is called after, it won't catch the first one. I don't know why it's working in your first test though, but it sounds sketchy. The second test "works" (or not) as expected however.

const emitter = createSomeEmitter();

emitter.emit('foo');

// Will never be resolved
await pEvent(emitter, 'foo');

const emitter = createSomeEmitter();

// Will be resolved
await pEvent(emitter, 'foo');

emitter.emit('foo');

[jwalton]

kv.watchKey() essentially does:

    watch = new EventEmitter();
    process.setTimeout(() => watch.emit('change'), 0);
    return watch;

So I have time to add a listener before the event is emitted.

[jwalton]

Oh... I wonder if the library I'm using to talk to etcd is being overly clever, and emitting a change event right when I call setKey instead of waiting for etcd to send us the change. That would explain the behavior.

[kevva]

Yeah, probably. I just tried this and it passed:

const createEmitter = () => {
    const e = new EventEmitter();
    setTimeout(() => e.emit('foo', 'bar'), 0);
    return e;
};

const emitter = createEmitter();
const result = await pEvent(emitter, 'foo');

t.is(result, 'bar');

[jwalton]

Yeah, I tried something similar and it passed for me too. Sorry to waste your time. :P Thanks for the awesome library, though!

…

On Fri, Sep 27, 2019, 15:44 Kevin Mårtensson ***@***.***> wrote: Yeah, probably. I just tried this and it passed: const createEmitter = () => { const e = new EventEmitter(); setTimeout(() => e.emit('foo', 'bar')); return e; }; const emitter = createEmitter();const result = await pEvent(emitter, 'foo'); t.is(result, 'bar'); — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#27?email_source=notifications&email_token=AANQL63ZCVM55SGKLCS2RYDQLZPBLA5CNFSM4I25I7T2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7Z5E5Y#issuecomment-536072823>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANQL6YLFPW6ASBIUSR3WVDQLZPBLANCNFSM4I25I7TQ> .