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.

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

hyp-repair fill-missing Invalid URL error. #143

Open
NathanielRMoss opened this issue Nov 1, 2023 · 1 comment
Open

hyp-repair fill-missing Invalid URL error. #143

NathanielRMoss opened this issue Nov 1, 2023 · 1 comment

Comments

@NathanielRMoss
Copy link

NathanielRMoss commented Nov 1, 2023

I was able to connect and "Finished checking forked blocks!" using ./hyp-repair scan mymainnet. My hyperion indexer and api are running. But when I try to use the fix commands, I'm getting an invalid URL. The chain file is there (if I change the name or move the file, I get a ENOENT: no such file or directory).

khype@koyn-hyperion:~/hyperion$ git show
commit 32145b6 (HEAD -> main, origin/main, origin/HEAD)
Author: Igor Lins e Silva [email protected]
Date: Tue Oct 10 21:21:35 2023 -0300

khype@hyperion:~/hyperion$ ./hyp-repair fill-missing kmainnet .repair/mymainnet-4-33864607-missing-blocks.json
/home/khype/hyperion/node_modules/ws/lib/websocket.js:676
throw new SyntaxError(Invalid URL: ${address});
^
SyntaxError: Invalid URL: ws://localhost:undefined/local
at initAsClient (/home/khype/hyperion/node_modules/ws/lib/websocket.js:676:13)
at new WebSocket (/home/khype/hyperion/node_modules/ws/lib/websocket.js:85:7)
at fillMissingBlocksFromFile (/home/khype/hyperion/scripts/hyp-repair.js:633:24)
at Command.repairMissing (/home/khype/hyperion/scripts/hyp-repair.js:178:11)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
Node.js v18.16.0

@3dkrender
Copy link

I noticed this issue has been open for a while, and I’d like to provide some clarification to help close it in case others encounter the same problem.

In the connections.json file, there is an optional parameter called control_port. While it’s not required for the normal operation of the indexer, it is necessary for the repair tool (hyp-repair) to successfully connect to the indexer.

Here’s an example configuration from example-connections.json for reference:

"chains": {
  "eos": {
    "name": "EOS Mainnet",
    "chain_id": "aca376f206b8fc25a6ed44dbdc66547c36c6c33e3a119ffbeaef943642f0e906",
    "http": "http://127.0.0.1:8888",
    "ship": "ws://127.0.0.1:8080",
    "WS_ROUTER_HOST": "127.0.0.1",
    "WS_ROUTER_PORT": 7001,
    "control_port": 7002
  }
}

Important Notes:

  1. Default Value: The control_port defaults to 7002 and is automatically assigned by the indexer if not explicitly included in the configuration.
  2. For Upgrades: Users installing a newer version of Hyperion likely won’t face this issue, but it may affect those upgrading from older versions where the control_port parameter was absent.

By ensuring that control_port is explicitly included in the configuration, the hyp-repair tool should work as expected.


Proposal for the Project Maintainers

Note for @igorls:
Since control_port is an optional parameter that may be omitted and the indexer assigns a default value automatically, a similar approach could be applied to the hyp-repair tool.

This could be achieved by modifying the line:

const controlPort = config.chains[chain].control_port;

to:

const controlPort = config.chains[chain].control_port || 7002;

in the file scripts/hyp-repair.ts.

This small change would ensure backward compatibility with older configurations where control_port was not explicitly defined.

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

No branches or pull requests

2 participants