Skip to content

unhandledRejection: Promise { <rejected> TypeError [ERR_MISSING_ARGS]: The "options" or "port" or "path" argument must be specified #252

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
700software opened this issue Dec 15, 2021 · 7 comments · Fixed by #259

Comments

@700software
Copy link

unhandledRejection: Promise {
  <rejected> TypeError [ERR_MISSING_ARGS]: The "options" or "port" or "path" argument must be specified
      at new NodeError (node:internal/errors:329:5)
      at Socket.connect (node:net:932:11)
      at Object.connect (node:net:197:17)
      at Object.connect (C:\...\node_modules\postgres\lib\connection.js:390:13) {
    code: 'ERR_MISSING_ARGS'
  }
}

This error occurs intermittently.

I have an unusual config here: { ..., idle_timeout:1, max:5 }

Error is occuring here:

: net.connect(

When error occurs it is because i == 1 but I only have one host and port so net.connect is called with options undefined, undefined instead of the port number.

I think what is happening is multiple connections are trying to be reopened simultaneously

@700software 700software changed the title unhandledRejection: Promise { <rejected> TypeError [ERR_MISSING_ARGS]: The "options" or "port" or "path" argument must be specified at new NodeError (node:internal/errors:329:5) at Socket.connect (node:net:932:11) at Object.connect (node:net:197:17) at Object.connect (C:\GitHub\rcsng\nextjs\node_modules\postgres\lib\connection.js:392:13) { code: 'ERR_MISSING_ARGS' } } unhandledRejection: Promise { <rejected> TypeError [ERR_MISSING_ARGS]: The "options" or "port" or "path" argument must be specified Dec 15, 2021
@700software
Copy link
Author

700software commented Dec 15, 2021

I would move the i >= options.host.length && (i = 0) out of the onclose and put it immediately after net.connect but that would mess up the failover logic

!ended && !succeeded && i < options.host.length

@700software
Copy link
Author

700software commented Dec 15, 2021

Maybe only reopening one at a time would work.. I think multiple are trying to be reopened (due to multiple sql`...` calls) after all had idle timeout.

@porsager
Copy link
Owner

Thanks a lot for the good description @700software .. I'm currently in the process of a reimplementation of the connection handling since the current implementation doesn't hold up to the requirement of the features it needs to support, as well as more options for dynamic queries, cancellation of queries, max connection lifetime etc. The goal is to resolve issues like these at the same time.

@porsager
Copy link
Owner

Also, just to be sure, this is with beta 11 correct?

@700software
Copy link
Author

correct, just verified

@porsager
Copy link
Owner

porsager commented Dec 15, 2021

I'll think about removing the failover logic for now since it's buggy and affecting regular usage..

@700software
Copy link
Author

beta8 seems to be fine

@porsager porsager mentioned this issue Jan 11, 2022
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants