search

relaycorp / relaynet-gateway-android

Awala Gateway for Android
https://relaynet.network/users
GNU General Public License v3.0
9 stars 0 forks source link

fix(deps): update to PoWeb library to 1.5.80 #727

Closed sdsantos closed 9 months ago

sdsantos commented 10 months ago

Fixes https://github.com/relaycorp/awala-poweb-jvm/issues/323

gnarea commented 10 months ago

FYI @sdsantos , CI is failing

sdsantos commented 10 months ago

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 commented 9 months ago

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 commented 9 months ago

@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 commented 9 months ago

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

sdsantos commented 9 months ago

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

Also happening to https://github.com/relaycorp/relaynet-courier-android/pull/599

gnarea commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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[bot] commented 9 months ago

:tada: This PR is included in version 1.9.1 :tada:

The release is available on:

Your semantic-release bot :package::rocket: