Fake server responds multiple times to single request, throws INVALID_STATE_ERR on subsequent requests

[n1ywb]

We understand you have a problem and are in a hurry, but please provide us with some info to make it much more likely for your issue to be understood, worked on and resolved quickly.

• Sinon version : 1.15, 3.2.0
• Environment : chrome 60
• Example URL : https://codepen.io/anon/pen/eEEJVy?editors=0012
• Other libraries you are using: none

What did you expect to happen?

when I set up two responders with server.respondWith only the first matching one should fire for any given request

What actually happens

first the wrong default one is handled for the given URL, then the correct one is handled which throws an uncaught INVALID_STATE_ERR exception

How to reproduce

https://codepen.io/anon/pen/eEEJVy?editors=0012

Really long code sample or stacktrace

start
15:03:37.183 VM4447 console_runner-079c09a….js:1 requesting foo
15:03:37.185 VM4447 console_runner-079c09a….js:1 default requested
15:03:37.187 VM4447 console_runner-079c09a….js:1 FakeXMLHttpRequest {eventListeners: Object, readyState: 1, requestHeaders: Object, requestBody: null, status: 0…}
15:03:37.191 VM4447 console_runner-079c09a….js:1 foo requested
15:03:37.193 VM4447 console_runner-079c09a….js:1 FakeXMLHttpRequest {eventListeners: Object, readyState: 4, requestHeaders: Object, requestBody: null, status: 404…}
15:03:37.194 VM4451 sinon.js:6427 Uncaught Object {name: "Error", message: "Fake server request processing threw exception: INVALID_STATE_ERR - 4", stack: "Error: INVALID_STATE_ERR - 4↵ at verifyRequestO…/sinon@3/pkg/sinon.js:7406:18)↵ at pen.js:42:5"}
throwLoggedError @ VM4451 sinon.js:6427
logError @ VM4451 sinon.js:6437
processRequest @ VM4451 sinon.js:6894
handleRequest @ VM4451 sinon.js:6812
xhrObj.onSend @ VM4451 sinon.js:6784
send @ VM4451 sinon.js:7406
(anonymous) @ VM4452 pen.js:35
(anonymous) @ VM4452 pen.js:37

[fatso83]

Moved to sinonjs/nise#8

[fatso83]

@mroderick Are we supposed to move and close these issues that relate to libraries that we depend on?

[mroderick]

@mroderick Are we supposed to move and close these issues that relate to libraries that we depend on?

I think that is a great strategy

[mroderick]

Or, at least do most of the work in the dependency repo, and just confirm the resolution here

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.