Instability in latest stable versions (v0.5.5v and v0.5.5w)

[CyberDenner]

I have been using RethinkDNS for nearly two years now and it's a great app. While there have always been occasional bugs, I could usually find workarounds but the latest stable releases represent a significant stability regression compared to previous versions, including earlier betas like 0.5.5u. Previously workable setups are now failing consistently.

My knowledge is limited on this topic, but these specific behaviors seem clearly wrong:

Race condition in wireguard assignment: Rethink now allows assigning the same application in two or more wireguard tunnels simultaneously, an issue that did not exist in version 0.5.5u.

Widespread tunnel failures: Almost all of my wireguard profiles (4 out of 5 servers using multihop routing across different countries and locations) are unstable or failing after the update. It seems unlikely for four distinct external servers to break simultaneously without a client side change. I even tried adding some new wireguard profiles but it keeps failing.

DNS performance degradation: DNS resolution feels less reliable regardless of configuration.

I have disabled most experimental options with no great improvement. I am using v0.5.5w on Android 15

rethink_app_logs_v0.5.5w_1781973437550.zip

[actionated]

I cannot relate, besides the v0.5.5v release which broke some things with WireGuard (issues that were quickly fixed), I've found these new releases to be exceptionally stable. Some things to consider:

Clear app data between "big" releases, to avoid any unforeseen complications from how configurations were handled to how they are now.

Establishing a baseline of functionality before increasing the complexity of your setup could be helpful, so issues can be better pinpointed.

Assigning an app to two or more wireguard tunnels may not be undesirable, but if wanting specific routing, it may be in its current state. For example, if having tunnel A setup with lockdown and apps of choice and tunnel B with lockdown and always-on enabled would function so apps specifically selected in tunnel A would be routed through tunnel A (with lockdown) before tunnel B, and once/if A fails, the "catch-all" tunnel B would take over, it would make more sense. However, in its current state, lockdown will force the app through tunnel A without considering the always-on tunnel, keeping the app downed, and if an app is assigned to more than one tunnel with no toggles, the user has no choice in which is preferred. Perhaps an optional toggle to a WG tunnel to allow other available always-on tunnels to pick up the app in this event would be beneficial. Regarding the "race condition," assigning priority of preference to apps in a specific tunnel could make this behavior more logical.