almost every command on testnet results in timeout

[ddombrowsky]

Thus far, I have been unable to execute a single transaction doing anything on testnet.

Most actions will result in an error and require a reload with F5. Thus far I have been unable to send any test amounts to any accounts, or post any orders, or anything that I need to use Solar Wallet for.

Again, this is all on TESTNET. Is this wallet expected to run on testnet, or not?

This is version 0.26.1.

[andywer]

Strange. I tried it multiple times yesterday and today, also on version 0.26.1, and it worked for me every time 🤷‍♂️

Can you try again? Our horizon servers currently redirect to the Stellar Foundation ones, maybe they were experiencing overly high load while you were trying?

[ddombrowsky]

Strange. I tried it multiple times yesterday and today, also on version 0.26.1, and it worked for me every time

Can you try again? Our horizon servers currently redirect to the Stellar Foundation ones, maybe they were experiencing overly high load while you were trying?

It still exhibits the same behavior. I have tried connecting to the test network multiple times over the last few weeks, and I see the same timeouts.

The thing is, it does not do this on the public network. Yes, there are more than a few timeout issues, but they don't usually prevent the use of the application. Right now, I load the app, switch the toggle to "testnet", and 9 times out of 10 every account will say (after about 10 seconds) "request timed out". For the 1 out of 10 cases that it loads, when I open one of the accounts, it will then say "request timed out" on the detail screen just about every time.

I currently have 8 configured accounts on testnet, and 12 on public net.

Is there a debug logging mode I can try to get more information?

[ebma]

Hey @ddombrowsky, I would suspect that most of your requests for testnet accounts take longer than 10 seconds to resolve and that's why you see this error. To check if this is the case you can open the developer tools in Solar with "Ctrl+Shift+i" and head over to the "Network" tab. Then reload Solar with "Ctrl+r" and see if the status of the requests for your account data switch from (pending) to 200 eventually. It's normal to see status 404 for accounts that are not yet activated on the network (i.e. empty accounts).

We set the timeout of requests in the fetch queue to 10 seconds because it seemed to be a suitable value but it might be too low in your case.

[ddombrowsky]

This is just a guess, but perhaps it's trying to connect a even stream to each of the accounts in either the test or public network? And that is causing the horizon server to start blocking the request because it is too frequent?

I'm seeing a lot of "SSE Stream" errors before anything times out.

I'm also not seeing any HTTP timeouts in the network tab, which suggest to me that it's failing at a higher level.

Is there any way to turn off the streaming transaction connections? It looks like it's doing one per account on either test or public net, which in my case is a LOT.

[andywer]

Yeah, it creates one stream per account, but there is hardly a way around…

We do want to know when something about your account changes, so we can re-render updated balances, etc. We could also have one stream for everything only, streaming every transaction on the network and then filter on the client side. This will then likely result in a lot of traffic that is mostly completely worthless to you then, though 😕

[ddombrowsky]

@andywer
I'm fine with requiring a push of F5 to get updated balances.

Is there no way to turn off these streams without hacking the code directly?

[andywer]

@ddombrowsky No, there is no such option. Feel free to change the title and description of the issue into something like "Add option to disable live updates" or create a new issue if you think that would be valuable for you.

It's just tricky regarding the user experience.

[ebma]

The yellow warning messages for the streams are normal and it's still working as expected. I think what would help here is a mechanism to adjust the fetch queue timeout since you say that you don't see any timeouts in your network log.
I want to point out that the implementation will automatically throw an error ("Request timed out") once a request takes longer than 10 seconds BUT it can still go through afterward (hence you don't see an error in the network log). So we would have to add some way to tweak that number although I'm not sure how this would look like. It'd be possible to add a new app setting for this or read it from command-line arguments. But I guess adding it to the app settings might be confusing for the average user because he might not know what this is about and why he would want to change the number.