thoov
server.close() does not work??
describe.only('Websockets store handlers', () => {
let store;
beforeEach(() => {
store = createStore(ws,
applyMiddleware(
thunk,
promise,
)
);
});
it('connects the websocket', () => {
const server = new Server('ws://qorus.example.com/log/main');
store.subscribe(() => {
const { data } = store.getState();
expect(data).to.eql({
'log/main': {
loading: true,
connected: false,
error: false,
paused: false,
},
});
});
store.dispatch(actions.connect('log/main'));
server.close();
});
it('disconnects the websocket', () => {
const server = new Server('ws://qorus.example.com/log/main');
store.dispatch(actions.connect('log/main'));
store.subscribe(() => {
const { data } = store.getState();
expect(data).to.eql({
'log/main': {
loading: false,
connected: false,
error: false,
paused: false,
},
});
});
store.dispatch(actions.disconnect('log/main'));
server.close();
});
});
- Websockets store handlers disconnects the websocket: Error: A mock server is already listening on this url
Sorry, It's actually server.stop(), but that doesn't really matter since that one does not work either :)
@Foxhoundn Thanks for finding this. Let me dig into it and see what is happening
Because I don't have access to your store/actions its going to be hard for me to debug. Are you able to create a simpler example of this bug without hitting a store?
In the meantime I found that force a new connection avoid this issue. But if one test fail all the following tests will trigger this Error: A mock server is already listening on this url error.
new Server('socketioserverurl', {
forceNew: true,
reconnection: false
})
Is it possible that the problem is due to reconnection activated by default?
I'm having a similar "already listening" problem, and I tried
new Server('socketioserverurl', {
forceNew: true,
reconnection: false
})
and first typescript said those weren't valid keys, and when I @ts-ignore that error, I still have the same 'already listening' problem.
I'm also getting this error when I attempt multiple vitest cases, both concurrent and non-concurrent
In my case it was a sign of a bug in my code/test which was causing it not to reach the close call
