cannot read property 'socket' of undefined

[Dominic Tarr]

I got this error today, now, I am running this in a tab on my laptop,
so I'm always switching between networks, and suspending, and unsuspending.

maybe that is the problem?

..../node_modules/follow/lib/feed.js:199
    feed_request.req.socket.emit('agentRemove')
                    ^
TypeError: Cannot read property 'socket' of undefined
    at Request.<anonymous> (/Users/dominictarr/.nave/installed/0.10.10/lib/node_modules/npmd/node_modules/level-couch-sync/node_modules/follow/lib/feed.js:199:21)
    at Request.EventEmitter.emit (events.js:95:17)
    at ClientRequest.<anonymous> (/Users/dominictarr/.nave/installed/0.10.10/lib/node_modules/npmd/node_modules/level-couch-sync/node_modules/follow/node_modules/request/main.js:427:14)
    at ClientRequest.g (events.js:175:14)
    at ClientRequest.EventEmitter.emit (events.js:95:17)
    at HTTPParser.parserOnIncomingClient [as onIncoming] (http.js:1663:21)
    at HTTPParser.parserOnHeadersComplete [as onHeadersComplete] (http.js:122:23)
    at Socket.socketOnData [as ondata] (http.js:1556:20)
    at TCP.onread (net.js:510:27)

[Jason Smith]

@dominictarr Do you know offhand if maybe the request API changed (so I have a semver bug in my package.json)? If not, then it is probably some timing problem, where like you say, the object is not there yet, although that still feels like it might be in the request code.

Oh, wow, glancing at the code it looks like I need to upgrade to streams2

[Jason Smith]

@mikeal Did the request API change.

var some_req = request(/* some stuff */)
console.log('some_req.req is %s', typeof some_req.req)

Could that ever say "undefined" there? Thanks.

[Dominic Tarr]

normally this works, but some times I get crashes,
but I usually don't notice for a while, given that I'm running it in the background.

I suspect that this is related to how reconnects are handled.
What happens if my ip address changes while follow is running?

[Jason Smith]

That is a good point. I have tested changing the server IP but not much changing the client IP.

Just guessing, there are lots of ways a connection can fail if you change your IP. Basically it depends what OS you are on and what is the state of its networking when Follow attempts a retry. (And possibly, the way that state evolves could be a factor too, but I'm not sure.)

So, for example, you sleep while on WiFi then you wake in a vast field. There is no network at all and so even a name lookup will fail. (And come to think of it, doesn't Node do its own name resolution, not using the OS?) If there is a network but no DHCP, something similar could happen. If there is a network but it is slow, there will be some kind of timeout.

Anyway, Follow is supposed to handle all of these and just try over and over. But this one is slipping through its grasp. I think it is some sort of misunderstanding about the request object and when req.req (i.e. the lower-level http request as a child in the higher-level Mikeal request) will be there.

[Dominic Tarr]

I've noticed that node keeps the connection open for ages, and it works if I can sleep and resume, and it must work sometimes, hmm, I am running into this occasionally, what information does the logger keep?
I can just log this and next time we'll be able to see what happened much better.