search

haveno-dex / haveno

Decentralized P2P exchange platform built on Monero and Tor
https://haveno.exchange
GNU Affero General Public License v3.0
1.02k stars 112 forks source link

Add API functions to start and stop local Monero node [$300] #137

Closed woodser closed 2 years ago

woodser commented 3 years ago

This issue requests adding new API functions to start and stop a local Monero node.

The following functions are requested as additions to HavenoDaemon.ts. Feedback is welcome.

API Function Return Description
havenod.startMoneroNode(rpcUsername: string, rpcPassword: string) void Start local monerod process, throw error if fails.
havenod.stopMoneroNode() void Stop local monerod process, throw error if fails.

How to implement

Start an internal monerod process using a constructor in MoneroDaemonRpc.java.

Refer to how monero-wallet-rpc instances are started and stopped in Haveno for reference as this pattern will be similar.

Follow these instructions to add and test new API functions end-to-end.

github-actions[bot] commented 3 years ago

There is a bounty on this issue, the amount is in the title. The bounty will be awarded to the first person(s) who resolves this issue. Read the full conditions in the 'bounties.md' file. If you are starting to work on this issue, please write a comment here, so that we can assign the issue to you and avoid duplicated work.

HashedMantisShrimp commented 3 years ago

Hi guys, I would like to take on this bounty on my spare time, I have never programmed in Java but have some minor experience with other languages and am quite familiar with the Linux CLI. As a matter of fact, I have already forked the project and am working on setting it up on my computer.

Could someone assign this bounty to me? Also, what is an acceptable delivery time-frame for a P2 issue of this sort?

HashedMantisShrimp commented 3 years ago

Hi guys, I would like to take on this bounty on my spare time, I have never programmed in Java but have some minor experience with other languages and am quite familiar with the Linux CLI. As a matter of fact, I have already forked the project and am working on setting it up on my computer.

Could someone assign this bounty to me? Also, what is an acceptable delivery time-frame for a P2 issue of this sort?

I should also mention that I'm having problems getting past the Deploy instructions on installing.md, specifically with make seednode.

Is this the place I should go to in order to clear my doubts and request help - Development discussions: Haveno Development (#haveno-dev:haveno.network) relayed on Libera (IRC) (#haveno-dev) ?

woodser commented 3 years ago

Excellent, I have assigned the issue to you.

I can help implement (or at least review) the constructor of MoneroDaemonRpc.java in monero-java that launches the daemon process. It should be nearly identical to the constructor in MoneroWalletRpc.java, and will need a corresponding test.

Would hope for a timeframe within the next month or two, as other API calls are being built.

HashedMantisShrimp commented 3 years ago

That timeframe sounds definitely reasonable! If I managed to finish this fast enough I'll jump onto other API bounties.

As for my issue, something went wrong when I was following this step

"Logs" for the errors found:

User@User:~/Documents/Projects/Monero/Haveno-Projs/haveno$ make seednode ./haveno-seednode \ --baseCurrencyNetwork=XMR_STAGENET \ --useLocalhostForP2P=true \ --useDevPrivilegeKeys=true \ --nodePort=2002 \ --appName=haveno-XMR_STAGENET_Seed_2002 \ make: ./haveno-seednode: Command not found make: *** [Makefile:36: seednode] Error 127

Same error happened when I ran make deploy, except it didn't recognize the 'screen' command.

Then I tried this:

User@User:~/Documents/Projects/Monero/Haveno-Projs/haveno/seednode$ make seednode make: ** No rule to make target 'seednode'. Stop. User@User:~/Documents/Projects/Monero/Haveno-Projs/haveno/seednode$ sh install_seednode_debian.sh [] Bisq Seednode installation script [] Updating apt repo sources [sudo] password for User: Hit:1 http://lt.archive.ubuntu.com/ubuntu focal InRelease Hit:2 http://lt.archive.ubuntu.com/ubuntu focal-updates InRelease Hit:3 http://dl.google.com/linux/chrome/deb stable InRelease Hit:4 https://download.docker.com/linux/ubuntu focal InRelease Hit:5 http://ppa.launchpad.net/mkusb/ppa/ubuntu focal InRelease Ign:6 http://ppa.launchpad.net/unit3/bfgminer/ubuntu focal InRelease Get:7 http://security.ubuntu.com/ubuntu focal-security InRelease [114 kB] Err:8 http://ppa.launchpad.net/unit3/bfgminer/ubuntu focal Release 404 Not Found [IP: 91.189.95.85 80] Ign:9 https://github.com/luke-jr/bfgminer.git focal InRelease Err:10 https://github.com/luke-jr/bfgminer.git focal Release 404 Not Found [IP: 140.82.121.4 443] Reading package lists... E: The repository 'http://ppa.launchpad.net/unit3/bfgminer/ubuntu focal Release' does not have a Release file. E: The repository 'https://github.com/luke-jr/bfgminer.git focal Release' does not have a Release file. User@User:~/Documents/Projects/Monero/Haveno-Projs/haveno/seednode$ sh install_seednode_debian.sh [] Bisq Seednode installation script [*] Updating apt repo sources Hit:1 http://lt.archive.ubuntu.com/ubuntu focal InRelease Hit:2 http://lt.archive.ubuntu.com/ubuntu focal-updates InRelease Hit:3 http://ppa.launchpad.net/mkusb/ppa/ubuntu focal InRelease Hit:4 http://dl.google.com/linux/chrome/deb stable InRelease Hit:5 https://download.docker.com/linux/ubuntu focal InRelease Ign:6 http://ppa.launchpad.net/unit3/bfgminer/ubuntu focal InRelease Err:7 http://ppa.launchpad.net/unit3/bfgminer/ubuntu focal Release 404 Not Found [IP: 91.189.95.85 80] Get:8 http://security.ubuntu.com/ubuntu focal-security InRelease [114 kB] Ign:9 https://github.com/luke-jr/bfgminer.git focal InRelease Err:10 https://github.com/luke-jr/bfgminer.git focal Release 404 Not Found [IP: 140.82.121.4 443] Reading package lists... E: The repository 'http://ppa.launchpad.net/unit3/bfgminer/ubuntu focal Release' does not have a Release file. E: The repository 'https://github.com/luke-jr/bfgminer.git focal Release' does not have a Release file.

I also encountered a minor "error" during the first step when I ran make, should I paste that one as well?

woodser commented 3 years ago

@erciccione Something you can help with?

erciccione commented 3 years ago

@HashedMantisShrimp what OS are you on? Looks like a local problem. Also from a quick check on that Error 127 there could be an issue with your $PATH.

Same error happened when I ran make deploy, except it didn't recognize the 'screen' command.

Make sure you have screen installed if you are trying make deploy, but if it doesn't work with make seednode i doubt will work anyway.

install_seednode_debian.sh

This is a script we inherit from Bisq, it's not really update to work with Haveno.

HashedMantisShrimp commented 3 years ago

Thank you, I will look into it! I was under the impression that this was a Haveno specific problem (because of the ./haveno-seednode command not found), since it's make related shouldnt be too hard to fix. Am using an Ubuntu 20.04 btw.

woodser commented 3 years ago

The problem appears to be that the ./haveno-seednode executable has not been built. This suggests make didn't complete successfully. Do you see any errors when you run make?

HashedMantisShrimp commented 3 years ago

@woodser, that's the same conclusion I came to and was about to edit my other comment. Yes I saw an error when I initially ran make but disregarded it, now I can't find the terminal window with the history. I'll start over so I can investigate the first error (Just realized this is what you suggested, nvm lol). I'll ping one of you if I can't resolve the issue with make

EDIT FINAL - make error log:

mkdir -p .localnet ./scripts/xmr_btc_deps.sh monero-bins-haveno-linux.tar.gz: OK -> Monero binaries downloaded and verified tar: Ignoring unknown extended header keyword 'LIBARCHIVE.xattr.security.selinux' tar: Ignoring unknown extended header keyword 'LIBARCHIVE.xattr.security.selinux' tar: Ignoring unknown extended header keyword 'LIBARCHIVE.xattr.security.selinux' bitcoin-0.21.1-x86_64-linux-gnu.tar.gz: OK -> Bitcoin binaries downloaded and verified ./gradlew build Starting a Gradle Daemon (subsequent builds will be faster)

Configure project : Pricenode: Skipping spot provider tests

FAILURE: Build failed with an exception.

Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0. Use '--warning-mode all' to show the individual deprecation warnings. See https://docs.gradle.org/6.6.1/userguide/command_line_interface.html#sec:command_line_warnings

BUILD FAILED in 33s make: *** [Makefile:18: build-haveno] Error 1

erciccione commented 3 years ago

That seems to be related to the change of checksum (#127 #132). We are looking into it.

HashedMantisShrimp commented 3 years ago

Ah okay. I will wait for that to be resolved then. Or is it okay if I just run with the proposed change? I could edit the file locally and go with that.

woodser commented 3 years ago

You can try manually reverting the checksum to 389d61b1b5a85eb2f23c582c3913ede49f80c9f2b553e4762382c836270e57e5.

HashedMantisShrimp commented 3 years ago

That worked, thanks!

woodser commented 2 years ago

The new hash should work and the old hash will stop working after clearing your gradle cache with rm -rf ~/.gradle and building clean with make clean && make.

HashedMantisShrimp commented 2 years ago

Actually, my build seems to work without the new hash - prior to this I had deleted my ~/.gradle files and ran make clean && make, there was no error so I ran make a second time, just to be sure:

User@User:~/Documents/Projects/Monero/Haveno-Projs/haveno$ make mkdir -p .localnet ./scripts/xmr_btc_deps.sh monero-bins-haveno-linux.tar.gz: OK -> Monero binaries downloaded and verified tar: Ignoring unknown extended header keyword 'LIBARCHIVE.xattr.security.selinux' tar: Ignoring unknown extended header keyword 'LIBARCHIVE.xattr.security.selinux' tar: Ignoring unknown extended header keyword 'LIBARCHIVE.xattr.security.selinux' bitcoin-0.21.1-x86_64-linux-gnu.tar.gz: OK -> Bitcoin binaries downloaded and verified ./gradlew build

Configure project : Pricenode: Skipping spot provider tests

Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0. Use '--warning-mode all' to show the individual deprecation warnings. See https://docs.gradle.org/6.6.1/userguide/command_line_interface.html#sec:command_line_warnings

BUILD SUCCESSFUL in 22s 118 actionable tasks: 5 executed, 113 up-to-date

User@User:~/Documents/Projects/Monero/Haveno-Projs/haveno$ cat gradle/witness/gradle-witness.gradle | grep -i com.github.JesusMcCloud:jtorctl 'com.github.JesusMcCloud:jtorctl:389d61b1b5a85eb2f23c582c3913ede49f80c9f2b553e4762382c836270e57e5',

Futhermore, all other make commands seem to work. If it's not that big a deal I'll keep using the old hash but I'll be sure to merge from your master branch before I submit my code.

HashedMantisShrimp commented 2 years ago

@woodser, were you guys aware of these errors? I followed these instructions to run the existing tests and found an error when using the docker command:

[2021-11-06 15:40:19.256][1][critical][main] [source/server/server.cc:113] error initializing configuration '/envoy.test.yaml': Unable to convert YAML as JSON: [2021-11-06 15:40:19.256][1][info][main] [source/server/server.cc:815] exiting Unable to convert YAML as JSON:

As well as an error when running npm start:

src/HavenoDaemon.tsx Line 130:13: Expected an assignment or function call and instead saw an expression @typescript-eslint/no-unused-expressions

I attempted to remove 'false' on line 130 (leaving only the semi colon) but then got this:

haveno-ui-poc/src/HavenoDaemon.tsx TypeScript error in /home/User/Documents/Projects/Monero/Haveno-Projs/haveno-ui-poc/src/HavenoDaemon.tsx(249,22): Argument of type 'TradeInfo | undefined' is not assignable to parameter of type 'TradeInfo | PromiseLike'. Type 'undefined' is not assignable to type 'TradeInfo | PromiseLike'. TS2345

247 |         if (err) reject(err);
248 |         else if (response.getFailureReason() && response.getFailureReason()!.getAvailabilityResult() !== AvailabilityResult.AVAILABLE) reject(response.getFailureReason()!.getDescription());

249 | else resolve(response.getTrade()); | ^ 250 | }); 251 | }); 252 | }

This is just an FYI, I'll get back at debugging this later today.

EDIT:

Am I wasting my time trying to get Haveno UI PoC to run w/o errors? I think not because at the end of the day I will be running tests to ensure my code hasn't broken anything, but I'd like a second opinion on this.

EDIT 2: Still haven't managed to fix it. Will keep it up whenever I find time in the coming week.

woodser commented 2 years ago

Regarding the jtorctl, ./gradlew build --refresh-dependencies will cause the latest hash in the repo to be used instead of the old cached hash.

error initializing configuration '/envoy.test.yaml': Unable to convert YAML as JSON:

I'm not seeing this error when starting the envoy proxy. Is your local path correct when invoking this command: docker run --rm -it -v ~/git/haveno-ui-poc/config/envoy.test.yaml:/envoy.test.yaml -p 8080:8080 -p 8081:8081 envoyproxy/envoy-dev:8a2143613d43d17d1eb35a24b4a4a4c432215606 -c /envoy.test.yaml ?

As well as an error when running npm start:

src/HavenoDaemon.tsx Line 130:13: Expected an assignment or function call and instead saw an expression @typescript-eslint/no-unused-expressions

Good catch, opened a PR to correctly set this parameter: https://github.com/haveno-dex/haveno-ui-poc/pull/26

Am I wasting my time trying to get Haveno UI PoC to run w/o errors? I think not because at the end of the day I will be running tests to ensure my code hasn't broken anything, but I'd like a second opinion on this.

Definitely not. It's most important that the end-to-end tests run, and the UI POC should run successfully if the tests run.

Still haven't managed to fix it.

Please keep us posted.

FYI: I have implemented changes in monero-java to support launching monerod as an internal process for this issue to use. It will be available in the next release of monero-java in the coming days.

woodser commented 2 years ago

FYI monero-java 0.5.8 is released which supports starting an internal monerod process as a constructor of MoneroDaemonRpc.java to support this issue.

randall-coding commented 2 years ago

I'm not seeing this error when starting the envoy proxy. Is your local path correct when invoking this command: docker run --rm -it -v ~/git/haveno-ui-poc/config/envoy.test.yaml:/envoy.test.yaml -p 8080:8080 -p 8081:8081 envoyproxy/envoy-dev:8a2143613d43d17d1eb35a24b4a4a4c432215606 -c /envoy.test.yaml ?

I'm running into the same error on my machine.

Here's what I'm doing: $ cd haveno-ui-poc

$ docker run --rm --add-host host.docker.internal:host-gateway -it -v ~/git/haveno-ui-poc/config/envoy.yaml:/envoy.yaml -p 8080:8080 envoyproxy/envoy-dev:8a2143613d43d17d1eb35a24b4a4a4c432215606 -c /envoy.yaml

I found a couple example of people running into the same error, but at least one looks like it doesn't apply (since we are using -c already) and the other I'm not sure about but seems related (something about running docker from a network drive).

https://github.com/googleapis/kiosk/issues/38 https://github.com/dotnet-architecture/eShopOnContainers/issues/1534

I'm not sure if part of the issue I'm having is not fully understanding the docker command. For example on this command -v ~/git/haveno-ui-poc/config/envoy.yaml:... I don't know if the ~/git/haveno-ui-poc/config/envoy.yaml referencing a local file or something on the network?

woodser commented 2 years ago

$ docker run --rm --add-host host.docker.internal:host-gateway -it -v ~/git/haveno-ui-poc/config/envoy.yaml:/envoy.yaml -p 8080:8080 envoyproxy/envoy-dev:8a2143613d43d17d1eb35a24b4a4a4c432215606 -c /envoy.yaml

This command assumes the haveno-ui-poc project is located at ~/git/haveno-ui-poc. You should modify to use your path if it's different.

I've clarified the instructions in https://github.com/haveno-dex/haveno-ui-poc/pull/29 to cd haveno-ui-poc then docker run --rm --add-host host.docker.internal:host-gateway -it -v ./config/envoy.yaml:/envoy.yaml -p 8080:8080 envoyproxy/envoy-dev:8a2143613d43d17d1eb35a24b4a4a4c432215606 -c /envoy.yaml

randall-coding commented 2 years ago

Thanks, I tried that previously but then I received this error

docker: Error response from daemon: create ./config/envoy.yaml: "./config/envoy.yaml" includes invalid characters for a local volume name, only "[a-zA-Z0-9][a-zA-Z0-9_.-]" are allowed. If you intended to pass a host directory, use absolute path.

So I guess it needs to be an absolute path. Maybe we could do something like this

docker run --rm --add-host host.docker.internal:host-gateway -it -v $HAVENO_UI/config/envoy.yaml:/envoy.yaml -p 8080:8080 envoyproxy/envoy-dev:8a2143613d43d17d1eb35a24b4a4a4c432215606 -c /envoy.yaml

Where $HAVENO_UI is the absolute path to the havaeno-ui-poc folder. I don't know if that's good just my first thought.

But it does work now for me with the full path :+1: . I'm running on a Linux machine btw, not Mac if that makes a difference.

woodser commented 2 years ago

I updated the instructions so it's clear that the absolute path should be modified for your system.

randall-coding commented 2 years ago

I updated the instructions so it's clear that the absolute path should be modified for your system.

Thanks. I think what makes it so confusing is that docker doesn't give a file not found error even if that path doesn't exist locally. So I just assumed that path existed somewhere, whether it was local or remotely.

HashedMantisShrimp commented 2 years ago

I had the same findings as @Randall-Coding , furthermore I checked quite a few times and this is the correct file path for me (~/git/haveno-ui-poc), however I should stress that that folder only contains config/envoy files and nothing else, not sure if that's expected?

I'll check out the new instructions when I have time.

woodser commented 2 years ago

I should stress that that folder only contains config/envoy files and nothing else, not sure if that's expected?

The haveno-ui-poc project should contain all project files after running git clone https://github.com/haveno-dex/haveno-ui-poc, so missing folders or files is not expected.

~/git/haveno-ui-poc should count as a full path.

The latest instructions are now on master. Thanks.

HashedMantisShrimp commented 2 years ago

@woodser, AWESOME. It's finally working. I also see where my confusion happened, the docker commands seems to create a folder in the path specified if there isn't one already. Since I didn't "willingly" create the folder on that path, I just assumed it was meant to be this way.

Fetched the newest code from upstream and started using my own project path and voila! Haveno UI was running on localhost, however npm test failed. Don't know yet if I need to make some modifications to any paths or something. I also still havent updated to the latest monero-java version, will look into this tomorrow.

FAIL src/HavenoDaemon.test.ts ● Can get the version

RequestError: Error: connect ECONNREFUSED 127.0.0.1:38084

  at MoneroRpcConnection.sendJsonRequest (node_modules/monero-javascript/src/main/js/common/MoneroRpcConnection.js:224:18)

● Can get market prices

RequestError: Error: connect ECONNREFUSED 127.0.0.1:38084

  at MoneroRpcConnection.sendJsonRequest (node_modules/monero-javascript/src/main/js/common/MoneroRpcConnection.js:224:18)

● Can get balances

RequestError: Error: connect ECONNREFUSED 127.0.0.1:38084

  at MoneroRpcConnection.sendJsonRequest (node_modules/monero-javascript/src/main/js/common/MoneroRpcConnection.js:224:18)

● Can get offers

RequestError: Error: connect ECONNREFUSED 127.0.0.1:38084

  at MoneroRpcConnection.sendJsonRequest (node_modules/monero-javascript/src/main/js/common/MoneroRpcConnection.js:224:18)

● Can get my offers

RequestError: Error: connect ECONNREFUSED 127.0.0.1:38084

  at MoneroRpcConnection.sendJsonRequest (node_modules/monero-javascript/src/main/js/common/MoneroRpcConnection.js:224:18)

● Can get payment accounts

RequestError: Error: connect ECONNREFUSED 127.0.0.1:38084

  at MoneroRpcConnection.sendJsonRequest (node_modules/monero-javascript/src/main/js/common/MoneroRpcConnection.js:224:18)

● Can create crypto payment accounts

RequestError: Error: connect ECONNREFUSED 127.0.0.1:38084

  at MoneroRpcConnection.sendJsonRequest (node_modules/monero-javascript/src/main/js/common/MoneroRpcConnection.js:224:18)

● Can post and remove an offer

RequestError: Error: connect ECONNREFUSED 127.0.0.1:38084

  at MoneroRpcConnection.sendJsonRequest (node_modules/monero-javascript/src/main/js/common/MoneroRpcConnection.js:224:18)

● Invalidates offers when reserved funds are spent

RequestError: Error: connect ECONNREFUSED 127.0.0.1:38084

  at MoneroRpcConnection.sendJsonRequest (node_modules/monero-javascript/src/main/js/common/MoneroRpcConnection.js:224:18)

● Can complete a trade

RequestError: Error: connect ECONNREFUSED 127.0.0.1:38084

  at MoneroRpcConnection.sendJsonRequest (node_modules/monero-javascript/src/main/js/common/MoneroRpcConnection.js:224:18)

PASS src/App.test.tsx

Test Suites: 1 failed, 1 passed, 2 total Tests: 10 failed, 1 passed, 11 total Snapshots: 0 total Time: 2.305 s, estimated 51 s Ran all test suites.

woodser commented 2 years ago

Did you start monero-wallet-rpc on port 38084 per step 4 of the instructions? It can't connect.

HashedMantisShrimp commented 2 years ago

Yes it appears I did, noob mistake. I am following the instructions now and am still encountering some minor problems connecting to the wallet uri, probably need to change the port config on the test file. Luckily I have the rest of the day free, will leave a comment if I can't figure it out.

EDIT: This is the info I got after running make alice-daemon: Monero wallet uri: http://127.0.0.1:34153

If I run npm test without any changes to HavenoDaemon.test.ts, I get this error: Can get the version - RequestError: Error: connect ECONNREFUSED 127.0.0.1:64840

I then attempted to change the relevant line in the folder mentioned above, like so: const aliceWalletUrl = "http://127.0.0.1:34153"; and am now getting this error:

Can get the version

Http response at 400 or 500 level

  at new E (node_modules/grpc-web/index.js:21:1229)
  at Y (node_modules/grpc-web/index.js:56:272)
  at oc.<anonymous> (node_modules/grpc-web/index.js:55:61)
  at Ib (node_modules/grpc-web/index.js:33:182)
  at O (node_modules/grpc-web/index.js:32:614)
  at wc (node_modules/grpc-web/index.js:43:411)
  at yc (node_modules/grpc-web/index.js:46:228)
  at oc.Object.<anonymous>.n.W (node_modules/grpc-web/index.js:44:252)
  at oc.Object.<anonymous>.n.R (node_modules/grpc-web/index.js:44:231)
  at XMLHttpRequest.invokeTheCallbackFunction (node_modules/jsdom/lib/jsdom/living/generated/EventHandlerNonNull.js:18:28)
  at XMLHttpRequest.<anonymous> (node_modules/jsdom/lib/jsdom/living/helpers/create-event-accessor.js:35:32)
  at innerInvokeEventListeners (node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:338:25)
  at invokeEventListeners (node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:274:3)
  at XMLHttpRequestImpl._dispatch (node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:221:9)
  at fireAnEvent (node_modules/jsdom/lib/jsdom/living/helpers/events.js:18:36)
  at readyStateChange (node_modules/jsdom/lib/jsdom/living/xhr/XMLHttpRequest-impl.js:761:3)
  at EventEmitter.<anonymous> (node_modules/jsdom/lib/jsdom/living/xhr/XMLHttpRequest-impl.js:889:5)
  at Request.<anonymous> (node_modules/jsdom/lib/jsdom/living/xhr/xhr-utils.js:382:41)
  at IncomingMessage.<anonymous> (node_modules/jsdom/lib/jsdom/living/helpers/http-request.js:230:42)

Am I going about this the right way? I believe the port change is necessary but surely this errors are not expected

EDIT 2: I have been inspecting the logs from seednode, and it seems that Alice's Daemon port is 5555:

Connection 1 Age: 1 hour, 19 minutes, 34.300 seconds Peer: localhost:5555 Type: PEER Direction: Inbound UID: c8f32eed-0d71-4d4c-be2e-acb8aac3512f

Alice's log:

$ make alice-daemon ./haveno-daemon \ --baseCurrencyNetwork=XMR_STAGENET \ --useLocalhostForP2P=true \ --useDevPrivilegeKeys=true \ --nodePort=5555 \ --appName=haveno-XMR_STAGENET_Alice \ --apiPassword=apitest \ --apiPort=9999

But changing the daemon port on the test file like in the example below seems to give me more errors: const aliceDaemonUrl = "http://localhost:5555";

console.error Error: Error: Parse Error: Expected HTTP/ at Object.dispatchError (/home/User/Documents/Projects/Monero/Haveno-Projs/haveno-ui-poc/node_modules/jsdom/lib/jsdom/living/xhr/xhr-utils.js:63:19) at EventEmitter. (/home/User/Documents/Projects/Monero/Haveno-Projs/haveno-ui-poc/node_modules/jsdom/lib/jsdom/living/xhr/XMLHttpRequest-impl.js:655:18) at EventEmitter.emit (events.js:326:22) at Request. (/home/User/Documents/Projects/Monero/Haveno-Projs/haveno-ui-poc/node_modules/jsdom/lib/jsdom/living/xhr/xhr-utils.js:401:14) at Request.emit (events.js:314:20) at ClientRequest. (/home/User/Documents/Projects/Monero/Haveno-Projs/haveno-ui-poc/node_modules/jsdom/lib/jsdom/living/helpers/http-request.js:121:14) at ClientRequest.emit (events.js:314:20) at Socket.socketOnData (_http_client.js:481:9) at Socket.emit (events.js:314:20) at addChunk (_stream_readable.js:297:12) undefined

  at VirtualConsole.<anonymous> (node_modules/jsdom/lib/jsdom/virtual-console.js:29:45)
  at Object.dispatchError (node_modules/jsdom/lib/jsdom/living/xhr/xhr-utils.js:66:53)
  at EventEmitter.<anonymous> (node_modules/jsdom/lib/jsdom/living/xhr/XMLHttpRequest-impl.js:655:18)
  at Request.<anonymous> (node_modules/jsdom/lib/jsdom/living/xhr/xhr-utils.js:401:14)
  at ClientRequest.<anonymous> (node_modules/jsdom/lib/jsdom/living/helpers/http-request.js:121:14)

EDIT 3: I am now checking App.tsx and just noticed that the haveno daemon url has the same port as Alice's: const HAVENO_DAEMON_URL = "http://localhost:8080"; const aliceDaemonUrl = "http://localhost:8080"; Surely they can't both use the same port, unless they're one and the same? And if they are meant to be the same thing, what is port 5555 (which I mentioned on the previous edit) for?

EDIT 4: I suspect one of the tests might be failing due to errors in some functions from HavenoDaemon.ts, reason I say this is because my webpage says "version not available". I tried manually setting the version here (in App.tsx):

constructor(props: any) { super(props); this.state = {daemonVersion: "1.6.2"}; this.daemon = new HavenoDaemon(HAVENO_DAEMON_URL, HAVENO_DAEMON_PASSWORD); }

but to no avail, which seems to be due to this:

async componentDidMount() { try { this.setState({daemonVersion: await this.daemon.getVersion()}); } catch (err) { console.error(err); this.setState({daemonVersion: " not available"}); } } Which ultimately points to the getVersion function on HavenoDaemon.ts - still investigating

woodser commented 2 years ago

Monero wallet uri: http://127.0.0.1:34153

Yes this is the port to manually copy to the HavenoDaemon.test.ts config. It changes each time you launch Alice.

aliceDaemonUrl should remain http://localhost:8080.

5555 is the Haveno daemon URL which envoy proxies to/from port 8080 for Alice. The UI POC just shows Alice's daemon version. The tests use both Alice and Bob.

randall-coding commented 2 years ago

I'm running into the same issue and seeing Http response at 400 or 500 level

When I look up this error online I see some people get the error when they don't have envoy running. https://github.com/grpc/grpc-web/issues/769

I believe my envoy is running correctly. When I start it here is the last output it gives me before idling

[2021-11-15 15:06:12.657][1][info][main] [source/server/server.cc:745] all clusters initialized. initializing init manager [2021-11-15 15:06:12.657][1][info][config] [source/server/listener_manager_impl.cc:889] all dependencies initialized. starting workers [2021-11-15 15:06:12.659][1][warning][main] [source/server/server.cc:642] there is no configured limit to the number of allowed active connections. Set a limit via the runtime key overload.global_downstream_max_connections

Here are the steps I followed prior to running npm test make bitcoind running make monero-shared running make seednode running make arbitrator-desktop running make alice-daemon running updated alice's wallet portnumber on HavenoDaemon.test.ts make bob-daemon running envoy running monero-wallet-rpc running (I think) npm install (Node version 12.14)

Last output from monero-wallet-rpc before idling is

2021-11-15 14:53:30.625 I Binding on 127.0.0.1 (IPv4):38084 2021-11-15 14:53:32.442 W Starting wallet RPC server

Is that what we should expect?

I also noticed errors in the monero-wallet-rpc logs

ERROR wallet.wallet2 src/wallet/wallet2.cpp:3205 Blocks start before blockchain offset: 0 550000

Stacktrace:

ERROR   wallet.wallet2  src/wallet/wallet2.cpp:3205 Blocks start before blockchain offset: 0 550000
2021-11-15 15:18:30.161 [RPC0]  ERROR   wallet.wallet2  src/wallet/wallet2.cpp:2687 !m_blockchain.is_in_bounds(current_index). THROW EXCEPTION: error::out_of_hashchain_bounds_error
2021-11-15 15:18:30.161 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:133  Exception: tools::error::out_of_hashchain_bounds_error
2021-11-15 15:18:30.161 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:134  Unwound call stack:
2021-11-15 15:18:30.169 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [1]  0x10d) [0x5599ee92d66d]:__wrap___cxa_throw+0x10d) [0x5599ee92d66d]
2021-11-15 15:18:30.169 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [2]  0x1f9) [0x5599ee76ea99]:_ZN5tools5error15throw_wallet_exINS0_29out_of_hashchain_bounds_errorEJEEEvONSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEDpRKT0_+0x1f9) [0x5599ee76ea99]
2021-11-15 15:18:30.169 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [3]  0x272) [0x5599ee6c8a82]:_ZN5tools7wallet221process_parsed_blocksEmRKSt6vectorIN10cryptonote20block_complete_entryESaIS3_EERKS1_INS0_12parsed_blockESaIS8_EERmPSt3mapISt4pairImmEmSt4lessISG_ESaISF_IKSG_mEEE+0x272) [0x5599ee6c8a82]
2021-11-15 15:18:30.169 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [4]  0x699) [0x5599ee6fc3e9]:_ZN5tools7wallet27refreshEbmRmRbb+0x699) [0x5599ee6fc3e9]
2021-11-15 15:18:30.169 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [5]  0x2d) [0x5599ee6ff2ad]:_ZN5tools7wallet27refreshEbmRm+0x2d) [0x5599ee6ff2ad]
2021-11-15 15:18:30.169 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [6]  0x2a) [0x5599ee6ff2fa]:_ZN5tools7wallet27refreshEb+0x2a) [0x5599ee6ff2fa]
2021-11-15 15:18:30.169 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [7] /home/super/Haveno/haveno/.localnet/monero-wallet-rpc(+0x4dacf6) [0x5599ee4dacf6] 
2021-11-15 15:18:30.169 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [8] /home/super/Haveno/haveno/.localnet/monero-wallet-rpc(+0x4de740) [0x5599ee4de740] 
2021-11-15 15:18:30.169 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [9] /home/super/Haveno/haveno/.localnet/monero-wallet-rpc(+0x4d23d9) [0x5599ee4d23d9] 
2021-11-15 15:18:30.169 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [10] /home/super/Haveno/haveno/.localnet/monero-wallet-rpc(+0x4f2fc3) [0x5599ee4f2fc3] 
2021-11-15 15:18:30.169 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [11]  0x56f) [0x5599ee51a06f]:_ZN5boost4asio6detail9scheduler3runERNS_6system10error_codeE+0x56f) [0x5599ee51a06f]
2021-11-15 15:18:30.169 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [12]  0x162) [0x5599ee53dd42]:_ZN4epee9net_utils18boosted_tcp_serverINS0_4http19http_custom_handlerINS0_23connection_context_baseEEEE13worker_threadEv+0x162) [0x5599ee53dd42]
2021-11-15 15:18:30.169 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [13] /home/super/Haveno/haveno/.localnet/monero-wallet-rpc(+0x97bdda) [0x5599ee97bdda] 
2021-11-15 15:18:30.169 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [14]  0x9609) [0x7fab672b1609]:_64-linux-gnu/libpthread.so.0(+0x9609) [0x7fab672b1609]
2021-11-15 15:18:30.169 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [15]  0x43) [0x7fab671d2293]:_64-linux-gnu/libc.so.6(clone+0x43) [0x7fab671d2293]
2021-11-15 15:18:30.169 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172  
2021-11-15 15:18:30.243 [RPC0]  ERROR   wallet.wallet2  src/wallet/wallet2.cpp:3438 (m_blockchain.size() == stop_height || (m_blockchain.size() == 1 && stop_height == 0) ? false : true). THROW EXCEPTION: error::wallet_internal_error
2021-11-15 15:18:30.243 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:133  Exception: tools::error::wallet_internal_error
2021-11-15 15:18:30.243 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:134  Unwound call stack:
2021-11-15 15:18:30.252 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [1]  0x10d) [0x5599ee92d66d]:__wrap___cxa_throw+0x10d) [0x5599ee92d66d]
2021-11-15 15:18:30.252 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [2]  0x1df) [0x5599ee76e0df]:_ZN5tools5error15throw_wallet_exINS0_21wallet_internal_errorEJA26_cEEEvONSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEDpRKT0_+0x1df) [0x5599ee76e0df]
2021-11-15 15:18:30.252 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [3]  0x318b) [0x5599ee6feedb]:_ZN5tools7wallet27refreshEbmRmRbb+0x318b) [0x5599ee6feedb]
2021-11-15 15:18:30.252 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [4]  0x2d) [0x5599ee6ff2ad]:_ZN5tools7wallet27refreshEbmRm+0x2d) [0x5599ee6ff2ad]
2021-11-15 15:18:30.252 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [5]  0x2a) [0x5599ee6ff2fa]:_ZN5tools7wallet27refreshEb+0x2a) [0x5599ee6ff2fa]
2021-11-15 15:18:30.252 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [6] /home/super/Haveno/haveno/.localnet/monero-wallet-rpc(+0x4dacf6) [0x5599ee4dacf6] 
2021-11-15 15:18:30.252 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [7] /home/super/Haveno/haveno/.localnet/monero-wallet-rpc(+0x4de740) [0x5599ee4de740] 
2021-11-15 15:18:30.252 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [8] /home/super/Haveno/haveno/.localnet/monero-wallet-rpc(+0x4d23d9) [0x5599ee4d23d9] 
2021-11-15 15:18:30.252 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [9] /home/super/Haveno/haveno/.localnet/monero-wallet-rpc(+0x4f2fc3) [0x5599ee4f2fc3] 
2021-11-15 15:18:30.252 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [10]  0x56f) [0x5599ee51a06f]:_ZN5boost4asio6detail9scheduler3runERNS_6system10error_codeE+0x56f) [0x5599ee51a06f]
2021-11-15 15:18:30.252 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [11]  0x162) [0x5599ee53dd42]:_ZN4epee9net_utils18boosted_tcp_serverINS0_4http19http_custom_handlerINS0_23connection_context_baseEEEE13worker_threadEv+0x162) [0x5599ee53dd42]
2021-11-15 15:18:30.252 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [12] /home/super/Haveno/haveno/.localnet/monero-wallet-rpc(+0x97bdda) [0x5599ee97bdda] 
2021-11-15 15:18:30.252 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [13]  0x9609) [0x7fab672b1609]:_64-linux-gnu/libpthread.so.0(+0x9609) [0x7fab672b1609]
2021-11-15 15:18:30.252 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [14]  0x43) [0x7fab671d2293]:_64-linux-gnu/libc.so.6(clone+0x43) [0x7fab671d2293]
2021-11-15 15:18:30.252 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172

ERROR wallet.wallet2 src/wallet/wallet2.cpp:3438 (m_blockchain.size() == stop_height || (m_blockchain.size() == 1 && stop_height == 0) ? false : true). THROW EXCEPTION: error::wallet_internal_error

ERROR   wallet.wallet2  src/wallet/wallet2.cpp:3438 (m_blockchain.size() == stop_height || (m_blockchain.size() == 1 && stop_height == 0) ? false : true). THROW EXCEPTION: error::wallet_internal_error
2021-11-15 15:18:30.243 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:133  Exception: tools::error::wallet_internal_error
2021-11-15 15:18:30.243 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:134  Unwound call stack:
2021-11-15 15:18:30.252 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [1]  0x10d) [0x5599ee92d66d]:__wrap___cxa_throw+0x10d) [0x5599ee92d66d]
2021-11-15 15:18:30.252 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [2]  0x1df) [0x5599ee76e0df]:_ZN5tools5error15throw_wallet_exINS0_21wallet_internal_errorEJA26_cEEEvONSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEDpRKT0_+0x1df) [0x5599ee76e0df]
2021-11-15 15:18:30.252 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [3]  0x318b) [0x5599ee6feedb]:_ZN5tools7wallet27refreshEbmRmRbb+0x318b) [0x5599ee6feedb]
2021-11-15 15:18:30.252 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [4]  0x2d) [0x5599ee6ff2ad]:_ZN5tools7wallet27refreshEbmRm+0x2d) [0x5599ee6ff2ad]
2021-11-15 15:18:30.252 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [5]  0x2a) [0x5599ee6ff2fa]:_ZN5tools7wallet27refreshEb+0x2a) [0x5599ee6ff2fa]
2021-11-15 15:18:30.252 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [6] /home/super/Haveno/haveno/.localnet/monero-wallet-rpc(+0x4dacf6) [0x5599ee4dacf6] 
2021-11-15 15:18:30.252 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [7] /home/super/Haveno/haveno/.localnet/monero-wallet-rpc(+0x4de740) [0x5599ee4de740] 
2021-11-15 15:18:30.252 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [8] /home/super/Haveno/haveno/.localnet/monero-wallet-rpc(+0x4d23d9) [0x5599ee4d23d9] 
2021-11-15 15:18:30.252 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [9] /home/super/Haveno/haveno/.localnet/monero-wallet-rpc(+0x4f2fc3) [0x5599ee4f2fc3] 
2021-11-15 15:18:30.252 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [10]  0x56f) [0x5599ee51a06f]:_ZN5boost4asio6detail9scheduler3runERNS_6system10error_codeE+0x56f) [0x5599ee51a06f]
2021-11-15 15:18:30.252 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [11]  0x162) [0x5599ee53dd42]:_ZN4epee9net_utils18boosted_tcp_serverINS0_4http19http_custom_handlerINS0_23connection_context_baseEEEE13worker_threadEv+0x162) [0x5599ee53dd42]
2021-11-15 15:18:30.252 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [12] /home/super/Haveno/haveno/.localnet/monero-wallet-rpc(+0x97bdda) [0x5599ee97bdda] 
2021-11-15 15:18:30.252 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [13]  0x9609) [0x7fab672b1609]:_64-linux-gnu/libpthread.so.0(+0x9609) [0x7fab672b1609]
2021-11-15 15:18:30.252 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172      [14]  0x43) [0x7fab671d2293]:_64-linux-gnu/libc.so.6(clone+0x43) [0x7fab671d2293]
2021-11-15 15:18:30.252 [RPC0]  INFO    stacktrace  src/common/stack_trace.cpp:172

Those errors are occurring whether monero-wallet-rpc is running or not. They are continuously happening with the other processes idling.

woodser commented 2 years ago

It looks to me like monero-wallet-rpc's wallet is synced against a different blockchain than the daemon is serving.

You could try deleting the funding wallet monero-wallet-rpc is using. The tests will automatically recreate and fund it.

randall-coding commented 2 years ago

Where is that wallet file located that I want to delete?

woodser commented 2 years ago

The default command from the instructions will create the wallet in haveno/.localnet.

The tests automatically create a wallet named "test_funding_wallet" unless a wallet is already funded on port 38084.

randall-coding commented 2 years ago

Hmmm. Well the only wallets I have funded right now are Bob and Alice I believe and I don't think they are on port 38084.

Also I'm not seeing anything in the haveno/.localnet that looks like a wallet (correct me if I'm wrong). Here is the contents of that folder bitcoin-0.21.1-x86_64-linux-gnu.tar.gz bitcoin-cli bitcoind monero-bins-haveno-linux.tar.gz monerod monero-wallet-rpc monero-wallet-rpc.log regtest stagenet

The default command from the instructions will create the wallet in haveno/.localnet.

I've been running cd ~/Haveno/haveno/.localnet/ && ./monero-wallet-rpc --daemon-address http://localhost:38081 --daemon-login superuser:abctesting123 --stagenet --rpc-bind-port 38084 --rpc-login rpc_user:abc123 --wallet-dir ./ --rpc-access-control-origins http://localhost:8080 from the instructions and it isn't yielding a start up error.

I wonder if I should just start this all from scratch and see if that resolves it.

woodser commented 2 years ago

it isn't yielding a start up error.

Good. The funding wallet is only created in haveno/.localnet when you run the tests.

You are still seeing the Http response at 400 or 500 level errors without the previous errors in monero-wallet-rpc console?

randall-coding commented 2 years ago

Yep I'm still seeing Http response at 400 or 500 level

without the previous errors in monero-wallet-rpc console

The errors were never in the monero-wallet-rpc console, they are only in the log file. Also they are generated even when monero-wallet-rpc command isn't running, so they must be being logged by a different process.

I may have fubared something along the way here. I think I'll just scrap everything and clone the repo again.

HashedMantisShrimp commented 2 years ago

@woodser @Randall-Coding I think I have nailed down the issue. Something is definitely wrong with the docker/envoy instance.

I say this because npm test returns the same errors (in addition to another) with or without docker running and also because of the findings Randall reported above. I checked and inspected that every single monero instance (wallet or daemon) are running or connecting to the correct/expected port, and they are.

The only thing that is different if docker isn't running, is that in addition to all the tests that failed previously, I got this error (gets printed out a bunch of times):

FAIL src/HavenoDaemon.test.ts ● Console

console.error
  Error: Error: connect ECONNREFUSED 127.0.0.1:8080
      at Object.dispatchError (/home/User/Documents/Projects/Monero/Haveno-Projs/haveno-ui-poc/node_modules/jsdom/lib/jsdom/living/xhr/xhr-utils.js:63:19)
      at EventEmitter.<anonymous> (/home/User/Documents/Projects/Monero/Haveno-Projs/haveno-ui-poc/node_modules/jsdom/lib/jsdom/living/xhr/XMLHttpRequest-impl.js:655:18)
      at EventEmitter.emit (events.js:326:22)
      at Request.<anonymous> (/home/User/Documents/Projects/Monero/Haveno-Projs/haveno-ui-poc/node_modules/jsdom/lib/jsdom/living/xhr/xhr-utils.js:401:14)
      at Request.emit (events.js:314:20)
      at ClientRequest.<anonymous> (/home/User/Documents/Projects/Monero/Haveno-Projs/haveno-ui-poc/node_modules/jsdom/lib/jsdom/living/helpers/http-request.js:121:14)
      at ClientRequest.emit (events.js:314:20)
      at Socket.socketErrorListener (_http_client.js:427:9)
      at Socket.emit (events.js:314:20)
      at emitErrorNT (internal/streams/destroy.js:92:8) undefined

So I am very inclined to believe the issue lies either with docker/envoy or a file that docker/envoy is supposed to use, or the very last thing that jumps to my mind is that I still have not updated my code to use the updated hash for jtorctl.

I'm not exactly familiar with docker or envoy though, so if the issue is related to that, it will take me a while. Meanwhile I'll go update that hash and see what happens.

EDIT: I also attempted to npm audit fix --force, did not help at all, broke the whole thing even more.

EDIT 2: I just noticed that npm start also runs the same, with or without docker, no additional errors.

@woodser Noob questions but, What exactly does the docker/envoy line try to accomplish? What is it supposed to enable when running and disable if it's not running, in other words, what components/parts of haveno are expected to fail without it? I read that it (envoy) helps manage subsystems/micro-services (?) but this doesn't really tell me anything.

woodser commented 2 years ago

What exactly does the docker/envoy line try to accomplish?

Docker is being used to run envoy as a proxy between the browser's http1 and grpc's htttp2. It's necessary for the browser to use the grpc api.

randall-coding commented 2 years ago

After building again I get this new error on the monero-wallet-rpc console after running npm test (last time I get no messages on that console).

2021-11-16 02:46:09.054 E e || !exists. THROW EXCEPTION: error::file_not_found 2021-11-16 02:46:09.093 W Español word 'asa' is shorter than its prefix length, 4 2021-11-16 02:46:09.094 W Español word 'ave' is shorter than its prefix length, 4 2021-11-16 02:46:09.094 W Español word 'boa' is shorter than its prefix length, 4 2021-11-16 02:46:09.094 W Español word 'cal' is shorter than its prefix length, 4 2021-11-16 02:46:09.095 W Español word 'dar' is shorter than its prefix length, 4 2021-11-16 02:46:09.096 W Español word 'don' is shorter than its prefix length, 4 2021-11-16 02:46:09.096 W Español word 'dos' is shorter than its prefix length, 4 2021-11-16 02:46:09.096 W Español word 'eco' is shorter than its prefix length, 4 2021-11-16 02:46:09.096 W Español word 'eje' is shorter than its prefix length, 4 2021-11-16 02:46:09.097 W Español word 'fax' is shorter than its prefix length, 4...

And this time a test_funding_wallet was created in the .localnet/ folder

However I also received the same previous error on the console of the npm test command itself.

Http response at 400 or 500 level...

I have no problem spinning up the UI with npm start (though it did take a minute to work)

@HashedMantisShrimp you said the issue seems to be the docker/envoy instance, though I was able to make the localhost:3000 UI display correctly spinning up envoy using the test envoy command just like it worked with the normal envoy. So I wonder if we can pin down the problem to something called in the test script specifically and figure out what is trying to connect to what which causes this. From the stacktrace I'm not able to narrow down where in our code that error arises. I'm trying to see if envoy has any logs to look at.

HashedMantisShrimp commented 2 years ago

@Randall-Coding I guess I'll have to drop everything and make again, damn. Will check back in >8hrs and hopefully provide some new insights

woodser commented 2 years ago

And this time a test_funding_wallet was created in the .localnet/ folder

Sounds like you're very close to it working, especially if the UI is running on port 3000.

For the tests, confirming again that you're running the correct envoy config for the tests and not the UI.

Which tests pass and which tests fail? "Can get the version" should pass since we're seeing it work for the UI.

randall-coding commented 2 years ago

Which tests pass and which tests fail? "Can get the version" should pass since we're seeing it work for the UI.

Sorry I forgot to mention, I'm getting ten out of ten failure giving me the Http response at 400 or 500 level error.

Here is the stacktrace of the first one, but they all appear to be identical

● Can get the version Http response at 400 or 500 level at new E (node_modules/grpc-web/index.js:21:1229) at Y (node_modules/grpc-web/index.js:56:272) at oc. (node_modules/grpc-web/index.js:55:61) at Ib (node_modules/grpc-web/index.js:33:182) at O (node_modules/grpc-web/index.js:32:614) at wc (node_modules/grpc-web/index.js:43:411) at yc (node_modules/grpc-web/index.js:46:228) at oc.Object..n.W (node_modules/grpc-web/index.js:44:252) at oc.Object..n.R (node_modules/grpc-web/index.js:44:231) at XMLHttpRequest.invokeTheCallbackFunction (node_modules/jsdom/lib/jsdom/living/generated/EventHandlerNonNull.js:18:28) at XMLHttpRequest. (node_modules/jsdom/lib/jsdom/living/helpers/create-event-accessor.js:35:32) at innerInvokeEventListeners (node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:338:25) at invokeEventListeners (node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:274:3) at XMLHttpRequestImpl._dispatch (node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:221:9) at fireAnEvent (node_modules/jsdom/lib/jsdom/living/helpers/events.js:18:36) at readyStateChange (node_modules/jsdom/lib/jsdom/living/xhr/XMLHttpRequest-impl.js:761:3) at EventEmitter. (node_modules/jsdom/lib/jsdom/living/xhr/XMLHttpRequest-impl.js:889:5) at Request. (node_modules/jsdom/lib/jsdom/living/xhr/xhr-utils.js:382:41) at IncomingMessage. (node_modules/jsdom/lib/jsdom/living/helpers/http-request.js:230:42) ... Test Suites: 1 failed, 1 total Tests: 10 failed, 10 total

And this time I just got a new console output on the monero-wallet-rpc

2021-11-16 14:27:31.892 W Loaded wallet keys file, with public address: 51zx6c9bxPVJ9HFDkyfmkA86cNzN5FGDs6GjKBHz3D52RubDA4mYzHtWyPfpwA2dk3bbdH4Qx1Q5iAHKXgu6EFtXHoCrTLh

And I confirmed my envoy is using the envoy.test.yaml

randall-coding commented 2 years ago

And now that I look at it. The UI isn't actually showing the version.

Screenshot from 2021-11-16 08-38-05

From the console

Request URL: http://localhost:8080/io.bisq.protobuffer.GetVersion/GetVersion Request Method: POST grpc-message: upstream connect error or disconnect/reset before headers. reset reason: connection failure grpc-status: 14

I wonder if it is being really slow and hitting the timeout. That is what this said https://stackoverflow.com/questions/62987895/envoyproxy-upstream-connect-error-or-disconnect-reset-before-headers

EDIT: Nope increasing timeout for connection doesn't help (I tried a few minutes, it just waits longer to fail)

EDIT2: Maybe this just comes down to the config file not pointing to the right ports? https://github.com/envoyproxy/envoy/issues/15727 Are we supposed to be pointing to something inside the docker container like this?

address: host.docker.internal port_value: 9999

I'm still learning the config file, but is that saying Alice's deamon is something that should be running inside the docker container?

randall-coding commented 2 years ago

I just turned off my "Deny Incoming Connections" feature on my firewall. Not an ideal solution, but I am getting mostly passed tests now. 3/10 left that are failing

Tests failing are:

● Can get market prices ETH is not a valid currency code ● Invalidates offers when reserved funds are spent wallet is locked ● Can complete a trade wallet is locked

woodser commented 2 years ago

The first error is expected. I haven't seen the 2nd two errors before.

woodser commented 2 years ago

Perhaps it would help to delete Alice and Bob's wallets and the funding wallet so they're recreated.

randall-coding commented 2 years ago

I deleted all the wallet files but still getting the wallet is locked error. Appears to be Alice and Bob's based on their daemon's output.

I'm going to switch to another project today and be back tomorrow.

woodser commented 2 years ago

For reference the wallet is locked error occurs here in the code: https://github.com/haveno-dex/haveno/blob/4000fdc1e581b5608ae1d68f783000559f514913/core/src/main/java/bisq/core/api/CoreWalletsService.java#L464

Is there a stacktrace in the daemon consoles?

HashedMantisShrimp commented 2 years ago

Wait so, @Randall-Coding you are still getting the same errors (HTTP level 400 response) despite having started everything from scratch? So basically we were in the same place then.

For the record, I could easily get the UI running, but I couldn't get the Haveno UI version to display (it's exactly like what you posted above), AFAIK the UI version should show up - so let's try and tackle this issue first? What do you say @woodser? (Also I'm beginning to think this might take more than a month.)

And then you disabled deny inc connections and some tests have now passed, but the UI verison still wont show up? I guess we're exactly in the same place, except I haven't disabled my firewall.

@Randall-Coding Are you on Matrix's Haveno Development room? Would be nice if you were in there so we could move this convo over there.

EDIT1: I have finished wiping all repos and following all the steps from beginning to end - I also verified that my jtorcl hash is up to date, no problem on that end. Still getting the same errors on npm test (http level 400 response), will attempt to take down firewall later

EDIT2:

I just turned off my "Deny Incoming Connections" feature on my firewall. Not an ideal solution, but I am getting mostly passed tests now. 3/10 left that are failing

I am using Ufw on Ubuntu 20.04, I tried completely disabling the firewall, didn't help. But I think this is expected? Because all our processes are running on localhost inside the same machine (at least mine are), so enabling or disabling the firewall shouldn't affect them - I think.