[bug] No way to close the socket, producing 'open handles' errors

[mikemaccana]

Describe the bug There doesn't seem to be a way to close the socket (eg after tests run). So running any integration tests will result in warnings on jest and other test runners hat look for open sockets:

Jest has detected the following 1 open handles potentially keeping Jest from exiting:

  ●  TLSWRAP

      48 |
      49 |   // Play with the built in methods
    > 50 |   const user = await _twitterClient.v2.userByUsername(handle, {
         |                                        ^
      51 |     "user.fields": "verified",
      52 |   });
      53 |   return user.data.verified || null;

      at RequestHandlerHelper.buildRequest (node_modules/twitter-api-v2/dist/client-mixins/request-handler.helper.js:327:40)
      at RequestHandlerHelper.makeRequest (node_modules/twitter-api-v2/dist/client-mixins/request-handler.helper.js:352:14)
      at ClientRequestMaker.send (node_modules/twitter-api-v2/dist/client-mixins/request-maker.mixin.js:64:14)
      at TwitterApiv2.get (node_modules/twitter-api-v2/dist/client.base.js:110:47)
      at TwitterApiv2.userByUsername (node_modules/twitter-api-v2/dist/v2/client.v2.read.js:258:21)
      at src/twitter.ts:50:40
      at src/twitter.ts:8:71
      at Object.<anonymous>.__awaiter (src/twitter.ts:4:12)
      at checkIsVerified (src/twitter.ts:36:57)
      at src/twitter.test.ts:33:33
      at src/twitter.test.ts:8:71
      at Object.<anonymous>.__awaiter (src/twitter.test.ts:4:12)
      at Object.<anonymous> (src/twitter.test.ts:32:58)

To Reproduce

1. Run jest on any code that does new TwitterApi(bearerToken)

Expected behavior Some kind of disconnect() method on TwitterApiReadOnly instances. I've looked and I can't find it though. If this exists I'm sorry I can't find it!

Version

• Node.js version
• Lib version
• OS (especially if you use Windows)

Additional context Add any other context about the problem here.

[alkihis]

Socket is already manually closed at the end of a fetch. It seems like it is a similar issue as https://github.com/node-fetch/node-fetch/issues/1479 (this package uses the same HTTP logic as node-fetch). I'll check it when I have time, but I appreciate an help for debugging this issue (if its really problematic and not a false positive)