fix(deps): update to PoWeb library to 1.5.80

[sdsantos]

Fixes relaycorp/awala-poweb-jvm#323

[gnarea]

FYI @sdsantos , CI is failing

[sdsantos]

Not easy to get the instrumented tests to pass with Ktor v2. Always the same devices failing. They run fine locally, even with the same devices that fail on Firebase Test Lab. It's probably related with this:

https://youtrack.jetbrains.com/issue/KTOR-4878/RejectedExecutionException-when-a-server-having-an-active-Websockets-connection-is-stopped
https://youtrack.jetbrains.com/issue/KTOR-6595/Netty-event-executor-terminated-error-when-stopping-server-that-has-sslConnector

These web socket servers don't seem to like being restarted all the time...

We already have unit tests for this part of the code, we're basically doing larger integration tests with the Android background service running. How bad would it be to remove them? It's shame though... We basically started updating some libraries to ktor v2 so we should update the apps as well...

I tested the gateway app with Internet and Courier sync and it's working correctly.

[gnarea]

Hi @sdsantos!

Sorry, I missed this when I caught up with GH a few days ago.

These web socket servers don't seem to like being restarted all the time...

How about we don't do that then? I suspect we're restarting the server between tests because (1) it's easier and (2) it gives us better isolation between tests, but if that's problematic with Ktor 2 then reusing a single server instance across instrumentation tests sounds like the lesser of the two evils.

The coverage in this app isn't already where I'd like it to be (mainly because of its interaction with a courier app and the Internet gateway, which is difficult to test). Disabling so many instrumentation tests would make the situation worse, to the point I would no longer trust CI and I'd have to manually test every single PR.

[sdsantos]

@gnarea Spent a bit more time, and was able to make the troublesome tests pass just by staggering the tests (3 seconds of sleep after each test). Do you think that's an acceptable compromise?

[sdsantos]

Now the release step is acting up with a weird Could not resolve io.grpc:grpc-okhttp. Will retry it again tomorrow.

[gnarea]

Do you think that's an acceptable compromise?

Absolutely!

It all LGTM now. Thanks!

[sdsantos]

@gnarea Still failing release with Could not resolve io.grpc:grpc-okhttp:[1.61.0,2.0.0). Any idea?

Also happening to relaycorp/relaynet-courier-android#599

[gnarea]

No idea, but I get the impression it's using the wrong Maven repo in the release step but not the ci one.

I just created #729 to make the CI pipeline here identical to that of the Ping app, which works fine there, and I managed to replicate the issue in ci too.

I can't see any reference to JCenter, which according to Google is a reason why it might fail. Is there any chance we're using the wrong repo implicitly?

[gnarea]

Is there any chance we're using the wrong repo implicitly?

Never mind, I guess it'd also fail locally if that were the case.

[gnarea]

Ah, I think we were running that step with Gradle 8.5 instead of 8.1 because we were running gradle instead of ./gradlew.

The fix should be in #729 so once that's merged, we can merge it here.

[github-actions]

🎉 This PR is included in version 1.9.1 🎉

The release is available on:

• v1.9.1
• GitHub release

Your semantic-release bot 📦🚀