[BUG] CallZome not working (timeout) in Windows

[guillemcordoba]

[BUG] CallZome not working (timeout) in Windows

[guillemcordoba]

Well unfortunately I don't have access to the logs but it was failing still when only one existed in the network... So no I don't think that's the issue?

[mjbrisebois]

@ThetaSinner An issue was never made here on GitHub because it was only happening on the App Store DHT. I don't think it could be the same issue though because this one is happening on tests that create new DHTs.

[guillemcordoba]

Careful @jost-s and @ThetaSinner , the gather repo is still at holochain v0.2.2, since v0.2.3-rc.0 hasn't been made available in holonix yet. I compiled and built the gather installable version from this repo. Sorry if this has caused confusion, but the state of the published crates vs what we want to test makes it tricky for me too...

[ThetaSinner]

@guillemcordoba Understood. The app should be compatible with the rc I believe but I will bear that in mind.

There is a new Holonix version for the rc too if that's useful to you. There's now a 0_2_rc version you can point at instead of 0_2 which has the cached release candidate under it :)

[guillemcordoba]

Hey! This particular error is not present anymore no, so I'll close this.

[matthme]

Can confirm that the same happens in the launcher built for holochain 0.2.3-rc.0

[ThetaSinner]

Likewise, reproducible on the linked installer and when running on Launcher

[ThetaSinner]

I'm seeing lots of

[2023-11-13T12:10:55.879814200+00:00] INFO - [HOLOCHAIN 0.2.3-rc.0] �[2m2023-11-13T12:10:55.879737Z�[0m �[33m WARN�[0m �[2mkitsune_p2p::spawn::actor::space�[0m�[2m:�[0m �[2mC:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\kitsune_p2p-0.2.3-rc.0\src\spawn\actor\space.rs�[0m�[2m:�[0m�[2m1086:�[0m delegate broadcast error �[3merr�[0m�[2m=�[0mKitsuneError(Other(Custom { kind: Other, error: Timeout }))

[2023-11-13T12:10:55.879856100+00:00] INFO - [HOLOCHAIN 0.2.3-rc.0] �[2m2023-11-13T12:10:55.879737Z�[0m �[33m WARN�[0m �[2mkitsune_p2p::spawn::actor::space�[0m�[2m:�[0m �[2mC:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\kitsune_p2p-0.2.3-rc.0\src\spawn\actor\space.rs�[0m�[2m:�[0m�[2m1086:�[0m delegate broadcast error �[3merr�[0m�[2m=�[0mKitsuneError(Other(Custom { kind: Other, error: Timeout }))

[2023-11-13T12:10:55.879862600+00:00] INFO - [HOLOCHAIN 0.2.3-rc.0] �[2m2023-11-13T12:10:55.879735Z�[0m �[33m WARN�[0m �[2mkitsune_p2p::spawn::actor::space�[0m�[2m:�[0m �[2mC:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\kitsune_p2p-0.2.3-rc.0\src\spawn\actor\space.rs�[0m�[2m:�[0m�[2m1086:�[0m delegate broadcast error �[3merr�[0m�[2m=�[0mKitsuneError(Other(Custom { kind: Other, error: Timeout }))

[2023-11-13T12:10:55.879866900+00:00] INFO - [HOLOCHAIN 0.2.3-rc.0] �[2m2023-11-13T12:10:55.879752Z�[0m �[33m WARN�[0m �[2mkitsune_p2p::spawn::actor::space�[0m�[2m:�[0m �[2mC:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\kitsune_p2p-0.2.3-rc.0\src\spawn\actor\space.rs�[0m�[2m:�[0m�[2m1086:�[0m delegate broadcast error �[3merr�[0m�[2m=�[0mKitsuneError(Other(Custom { kind: Other, error: Timeout }))

[2023-11-13T12:10:55.974194500+00:00] INFO - [HOLOCHAIN 0.2.3-rc.0] �[2m2023-11-13T12:10:55.974121Z�[0m �[33m WARN�[0m �[2mkitsune_p2p::spawn::actor::space�[0m�[2m:�[0m �[2mC:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\kitsune_p2p-0.2.3-rc.0\src\spawn\actor\space.rs�[0m�[2m:�[0m�[2m1086:�[0m delegate broadcast error �[3merr�[0m�[2m=�[0mKitsuneError(Other(Custom { kind: Other, error: Timeout }))

Which suggests that communication with some other node isn't working correctly but that shouldn't cause zome calls to fail unless they need the network. Is that the case for the zome call that's failing?

[jost-s]

I've reproduced this problem under WSL with Holochain 0.2.3-rc.0 and also with 0.2.2. It's not a bug introduced by 0.2.3-rc.0. I'm going back through the versions to see since when this has been a problem.

[matthme]

0.2.3-beta-rc.1 worked fine for me on Windows when I tested this morning (launcher release 0.11.2). I only got the zome call timeouts with 0.2.3-rc.0.

[jost-s]

mewsfeed under 0.2.3-rc.0 has the same problem, with the difference that I can create a profile and then subsequent zome calls time out.

I see errors like these there

ERROR holochain::core::ribosome::real_ribosome: crates/holochain/src/core/ribosome/real_ribosome.rs:748: runtime_error=RuntimeError { source: User(WasmError { file: "crates/holochain/src/core/ribosome/host_fn/get_links.rs", line: 59, error: Host("timed out waiting for connection") }), wasm_trace: [] } zome=Zome { name: ZomeName("follows"), def: Wasm(WasmZome { wasm_hash: WasmHash(uhCok5E3_BBL_D7WGrmxTayY8g64Gs8R7nJ-tIdDLO7WwZOrJfYlY), dependencies: [ZomeName("follows_integrity")], preserialized_path: None }) } to_call=FunctionName("get_creators_for_follower")

[mjbrisebois]

If you can confirm that the request is being received by conductor, but it's not running the zome call (ie. a debug! line at the start of your function is not running), then this could be the same issue we ran into a couple of versions ago.

[jost-s]

Perplexing, I just run "gather" successfully on our hosted Windows machine. Windows 10, WSL 2, Holochain v0.2.3-rc.0. Runs perfectly fine.

Makes me think that it heavily depends on the machine's performance.

[ThetaSinner]

@mjbrisebois Could you point me at the issue you're referring to please?

@jost-s FWIW I have a powerful Windows machine that fails to run gather on every attempt. Sometimes I get a bit further and can create a profile then see the UI but that's as far as it gets for me. Doesn't mean that performance isn't relevant because I could still have different hardware that's part of the answer but I suspect it's only part of the answer. I am on WIndows 11 which I guess could make a difference but most of the Windows code probably hasn't changed really.

[jost-s]

@ThetaSinner Are you running the standalone app or the dev version?

[ThetaSinner]

I'm running the webhapp from here https://github.com/darksoil-studio/gather/releases/tag/v0.0.4 in the 0.11.3 launcher

**edit: So that I can run a custom build of Holochain based on 0.2.3-rc.0 that includes more logging. I can also change the log level in Launcher which I can't do with the installable version.

[jost-s]

Right, then please give the dev version (clone repo and run npm start) a shot too. I'm suspecting something buggy in the interplay between happ + environment (+ os).

[jost-s]

@guillemcordoba How did you build the rc.0 dependencies into the test release for alerts and the other zomes?

[guillemcordoba]

I didn't, I'm using hdk v2.2.0 to build everything for the app, and then installing it in a v0.2.3-rc.0 conductor. This is part of what I was trying to say with the previous comment. As @ThetaSinner said, I thought it should be compatible, and it was when I tested in local, so I assumed there were no version incompatibilities, as semver v0.2.2 should be compatible with v0.2.3.

[jost-s]

Right, then simply using holochain-0.2.3-rc.0 in the flake should be fine for testing with the cloned repo.

[dellams]

Did you guys get to the bottom of this? Was this an issue in 0.1.5 and 0.1.6? Thanks. :)

[abe-njama]

@dellams we're still debugging the zome call timeouts happening with wasmer v4.2.2. The wasmer bump had to be reverted so we can get around this problem.
This issue is actively happening in 0.2.3-rc.0 which had the newer wasmer version. 0.1.5 and 0.1.6 should be okay. They are running an older wasmer version.

[github-actions]

This item has been open for 30 days with no activity.

[github-actions]

This item has been open for 30 days with no activity.

[jost-s]

This bug should be fixed with #3208. Please try it out again and report back.