Extra requests for same hostname fail unexpectedly

[paulmelnikow]

Hi, thanks for your work on this useful library!

I'm using Nock Back to write some experimental tests for shields and I'm running into a bit of difficulty. Based on the description of the dryrun and record modes, I'd expect these modes to allow any http call. The behavior I'm seeing is that they don't allow http calls to hosts which have some nocks.

Here's a minimal-ish test:

const nockBack = require('nock').back
const fetch = require('node-fetch')

nockBack.fixtures = __dirname
nockBack.setMode('record')

nockBack('fixtures.json', (nockDone) => {
  fetch('http://httpbin.org/get?foo=1')
    .then(() => {
      nockDone()
      console.log('groovy')
    })
    .catch(err => { console.log(err) })
})

^^ Prints 'groovy' as expected.

const nockBack = require('nock').back
const fetch = require('node-fetch')

nockBack.fixtures = __dirname
nockBack.setMode('dryrun')

nockBack('fixtures.json', (nockDone) => {
  fetch('http://httpbin.org/get?foo=1')
    .then(() => {
      return fetch('http://httpbin.org/get?foo=2')
        .then(() => {
          nockDone()
          console.log('groovy')
        })
    })
    .catch(err => { console.log(err) })
})

^^ Expected 'groovy' but instead:

{ FetchError: request to http://httpbin.org/get?foo=2 failed, reason: Nock: No match for request {
  "method": "GET",
  "url": "http://httpbin.org/get?foo=2",
  "headers": {
    "accept-encoding": [
      "gzip,deflate"
    ],
    "user-agent": [
      "node-fetch/1.0 (+https://github.com/bitinn/node-fetch)"
    ],
    "connection": [
      "close"
    ],
    "accept": [
      "*/*"
    ]
  }
}
    at OverriddenClientRequest.<anonymous> (/Users/pnm/code/nock-back-bug-example/node_modules/node-fetch/index.js:133:11)
    at emitOne (events.js:96:13)
    at OverriddenClientRequest.emit (events.js:188:7)
    at /Users/pnm/code/nock-back-bug-example/node_modules/nock/lib/request_overrider.js:207:11
    at _combinedTickCallback (internal/process/next_tick.js:73:7)
    at process._tickCallback (internal/process/next_tick.js:104:9)
    at Module.runMain (module.js:606:11)
    at run (bootstrap_node.js:393:7)
    at startup (bootstrap_node.js:150:9)
    at bootstrap_node.js:508:3
  name: 'FetchError',
  message: 'request to http://httpbin.org/get?foo=2 failed, reason: Nock: No match for request {\n  "method": "GET",\n  "url": "http://httpbin.org/get?foo=2",\n  "headers": {\n    "accept-encoding": [\n      "gzip,deflate"\n    ],\n    "user-agent": [\n      "node-fetch/1.0 (+https://github.com/bitinn/node-fetch)"\n    ],\n    "connection": [\n      "close"\n    ],\n    "accept": [\n      "*/*"\n    ]\n  }\n}',
  type: 'system',
  errno: undefined,
  code: undefined }

By contrast, this example with a different hostname works fine:

const nockBack = require('nock').back
const fetch = require('node-fetch')

nockBack.fixtures = __dirname;
nockBack.setMode('dryrun')

nockBack('fixtures.json', (nockDone) => {
  fetch('http://httpbin.org/get?foo=1')
    .then(() => {
      return fetch('http://23.21.77.86/get?foo=2')
        .then(() => {
          nockDone()
          console.log('groovy')
        })
    })
    .catch(err => { console.log(err) })
})

I've combed through lib/back.js. My impression is that the problem is somewhere deeper. Any ideas?

[ianwsperber]

Interesting @paulmelnikow. I actually just encountered a very similar issue using nock.define, where I actually had to reverse the order of my fixtures to get nock to load the definitions correctly... Could you try reverse the scopes in fixtures to see if that affects the tests? Want to make sure it's not related.

[paulmelnikow]

Hmmm, interesting.

After running the first snippet I have one fixture. The second snippet crashes so it doesn't save anything else.

[
    {
        "scope": "http://httpbin.org:80",
        "method": "GET",
        "path": "/get?foo=1",
        "body": "",
        "status": 200,
        "response": {
            "args": {
                "foo": "1"
            },
            "headers": {
                "Accept": "*/*",
                "Accept-Encoding": "gzip,deflate",
                "Connection": "close",
                "Host": "httpbin.org",
                "User-Agent": "node-fetch/1.0 (+https://github.com/bitinn/node-fetch)"
            },
            "origin": "158.222.233.85",
            "url": "http://httpbin.org/get?foo=1"
        },
        "rawHeaders": [
            "Connection",
            "close",
            "Server",
            "gunicorn/19.7.1",
            "Date",
            "Fri, 21 Apr 2017 04:12:20 GMT",
            "Content-Type",
            "application/json",
            "Access-Control-Allow-Origin",
            "*",
            "Access-Control-Allow-Credentials",
            "true",
            "Content-Length",
            "322",
            "Via",
            "1.1 vegur"
        ]
    }
]

If I reverse the order of the http calls in the second snippet, the ?foo=2 call still fails.

Given that, I wouldn't suppose it's related to what you're seeing.

[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. We try to do our best, but nock is maintained by volunteers and there is only so much we can do at a time. Thank you for your contributions.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue and add a reference to this one if it’s related. Thank you!

[paulmelnikow]

Just found this linked from an old issue, and wonder if it's worth tracking down 😀

[mastermatt]

@paulmelnikow can this still be reproduced since v11? Maybe a runkit would be appropriate.

[paulmelnikow]

Yea, other than needing to update the IP address for httpbin.org this seems to behave just as before on master.

Here's a RunKit: https://runkit.com/melnikow/5d94feb55b27e1001bd046e5

If you swap the commented line and the uncommented line return fetch you can alternate between "groovy" (expected) and the error.

I suppose this has something to do with allowUnmocked…

[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. We try to do our best, but nock is maintained by volunteers and there is only so much we can do at a time. Thank you for your contributions.