Skip to content
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.

Sign up for GitHub

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

Jump to bottom

fix(common): Servers.startOnPreferredPort crashes when preferred port is taken #683

Closed
petermetz opened this issue Mar 18, 2021 · 0 comments · Fixed by #700
Closed

fix(common): Servers.startOnPreferredPort crashes when preferred port is taken #683

petermetz opened this issue Mar 18, 2021 · 0 comments · Fixed by #700
Assignees
@petermetz
Labels
bug Something isn't working

Comments

@petermetz
Copy link
Member

petermetz commented Mar 18, 2021 •
edited

Describe the bug

Servers.startOnPreferredPort() crashes when preferred port is taken

To Reproduce

  1. Use a port such as 3000
  2. Try to call Servers.startOnPreferredPort(3000) expecting it to find a new port automatically
  3. Observe that it crashes instead which is the exact opposite of what it's designed to do.

Expected behavior

It should return successfully with a random port allocation as the final resort fallback instead of crashing. That's the whole point of this particular implementation as used by the test at packages/cactus-test-api-client/src/test/typescript/integration/api-client-routing-node-to-node.test.ts

Logs/Stack traces

TAP version 13
# Routes to correct node based on ledger ID
not ok 1 Error: listen EADDRINUSE: address already in use 127.0.0.1:4100
  ---
    operator: fail
    stack: |-
      Error: Error: listen EADDRINUSE: address already in use 127.0.0.1:4100
          at Test.assert [as _assert] (/some/path/to/project/dir/cactus-scratch-1/node_modules/tape/lib/test.js:260:54)
          at Test.bound [as _assert] (/some/path/to/project/dir/cactus-scratch-1/node_modules/tape/lib/test.js:84:32)
          at Test.fail (/some/path/to/project/dir/cactus-scratch-1/node_modules/tape/lib/test.js:354:10)
          at Test.bound [as fail] (/some/path/to/project/dir/cactus-scratch-1/node_modules/tape/lib/test.js:84:32)
          at onError (/some/path/to/project/dir/cactus-scratch-1/node_modules/tape/lib/test.js:114:18)
          at processTicksAndRejections (internal/process/task_queues.js:97:5)
  ...

Killed

Screenshots

N/A

Cloud provider or hardware configuration:

Dev machine

Operating system name, version, build:

~$ printf "$(uname -srm)\n$(cat /etc/os-release)\n"
Linux 5.8.0-45-generic x86_64
NAME="Ubuntu"
VERSION="20.04.2 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.2 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

Hyperledger Cactus release version or commit (git rev-parse --short HEAD):

main @ e225b31

Hyperledger Cactus Plugins/Connectors Used

Quorum

Additional context

N/A

cc: @takeutak @sfuji822 @hartm @jonathan-m-hamilton @AzaharaC @jordigiam @kikoncuo @jagpreetsinghsasan
@petermetz petermetz added the bug Something isn't working label Mar 18, 2021
@petermetz petermetz self-assigned this Mar 18, 2021
petermetz added a commit to petermetz/cacti that referenced this issue Mar 22, 2021
@petermetz
fix(common): servers#startOnPreferredPort no graceful fallback hyperl…
2c55574 
…edger#683

The code of the method was not waiting for a promise to resolve
which was masking the underlying exception that the code
was supposed to catch and examine in order to determine if
it should perform a fallback of binding to port zero or not.
Fixed it by making sure the initial try of the preferred port
allocation is awaited for so that the exception is thrown
where it is expected by the algorithm.

Fixes hyperledger#683

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
@petermetz petermetz mentioned this issue Mar 22, 2021
Merged
petermetz added a commit to petermetz/cacti that referenced this issue Mar 23, 2021
@petermetz
fix(common): servers#startOnPreferredPort no graceful fallback hyperl…
38fafbd 
…edger#683

The code of the method was not waiting for a promise to resolve
which was masking the underlying exception that the code
was supposed to catch and examine in order to determine if
it should perform a fallback of binding to port zero or not.
Fixed it by making sure the initial try of the preferred port
allocation is awaited for so that the exception is thrown
where it is expected by the algorithm.

Fixes hyperledger#683

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz added a commit to petermetz/cacti that referenced this issue Mar 24, 2021
@petermetz
fix(common): servers#startOnPreferredPort no graceful fallback hyperl…
1ebfd32 
…edger#683

The code of the method was not waiting for a promise to resolve
which was masking the underlying exception that the code
was supposed to catch and examine in order to determine if
it should perform a fallback of binding to port zero or not.
Fixed it by making sure the initial try of the preferred port
allocation is awaited for so that the exception is thrown
where it is expected by the algorithm.

Fixes hyperledger#683

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz added a commit to petermetz/cacti that referenced this issue Mar 24, 2021
@petermetz
fix(common): servers#startOnPreferredPort no graceful fallback hyperl…
0541793 
…edger#683

The code of the method was not waiting for a promise to resolve
which was masking the underlying exception that the code
was supposed to catch and examine in order to determine if
it should perform a fallback of binding to port zero or not.
Fixed it by making sure the initial try of the preferred port
allocation is awaited for so that the exception is thrown
where it is expected by the algorithm.

Fixes hyperledger#683

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz added a commit to petermetz/cacti that referenced this issue Mar 26, 2021
@petermetz
fix(common): servers#startOnPreferredPort no graceful fallback hyperl…
c321ebb 
…edger#683

The code of the method was not waiting for a promise to resolve
which was masking the underlying exception that the code
was supposed to catch and examine in order to determine if
it should perform a fallback of binding to port zero or not.
Fixed it by making sure the initial try of the preferred port
allocation is awaited for so that the exception is thrown
where it is expected by the algorithm.

Fixes hyperledger#683

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz added a commit to petermetz/cacti that referenced this issue Mar 26, 2021
@petermetz
fix(common): servers#startOnPreferredPort no graceful fallback hyperl…
f71b832 
…edger#683

The code of the method was not waiting for a promise to resolve
which was masking the underlying exception that the code
was supposed to catch and examine in order to determine if
it should perform a fallback of binding to port zero or not.
Fixed it by making sure the initial try of the preferred port
allocation is awaited for so that the exception is thrown
where it is expected by the algorithm.

Fixes hyperledger#683

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz added a commit that referenced this issue Mar 26, 2021
@petermetz
fix(common): servers#startOnPreferredPort no graceful fallback #683
18f5af7 
The code of the method was not waiting for a promise to resolve
which was masking the underlying exception that the code
was supposed to catch and examine in order to determine if
it should perform a fallback of binding to port zero or not.
Fixed it by making sure the initial try of the preferred port
allocation is awaited for so that the exception is thrown
where it is expected by the algorithm.

Fixes #683

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
jordigiam pushed a commit to kikoncuo/cactus that referenced this issue Apr 8, 2021
@petermetz
fix(common): servers#startOnPreferredPort no graceful fallback hyperl…
ebccc40 
…edger#683

The code of the method was not waiting for a promise to resolve
which was masking the underlying exception that the code
was supposed to catch and examine in order to determine if
it should perform a fallback of binding to port zero or not.
Fixed it by making sure the initial try of the preferred port
allocation is awaited for so that the exception is thrown
where it is expected by the algorithm.

Fixes hyperledger#683

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@petermetz petermetz

Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix(common): servers#startOnPreferredPort no graceful fallback #683 petermetz/cacti
1 participant
@petermetz