2 Commits

Include renames

Author	SHA1	Message	Date
esefxdzandClaude Opus 5	e751a9d6e4	fix(session): don't release the session on a SOCKS5 Reconnect ... Regression from e67f0b9, shipped in 3.3.7. Reconnect repairs an orphaned proxy by tearing the runtime down and re-attaching to the session the device already holds. It does that through SessionTimer.disconnect(), which e67f0b9 taught to hand the session back to the server - so it destroyed the very session the following connect(resume: true) then asked for. Unawaited, so it raced: the resume either found the session already gone or removed moments later, surfacing as "Session not activated". disconnect() now takes release, and the Reconnect path passes false. Every other caller still hands the session back. Narrow in practice: SOCKS5 mode only, only the Settings Reconnect button, and the main-screen connect was unaffected because it mints a new session anyway. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-10-17 17:17:29 +03:00
esefxdzandClaude Opus 5	52e8cd8ca1	test: pin the session-lifecycle fixes against silent regression ... Source assertions, in the style of the existing release-verification test. Every behaviour here was found broken on a device and fixed today; none can be covered by an ordinary Dart test, because they live in the vendored Android runtime or need a live tunnel. They all regress silently, and each one looks like tidying when it does - inlining a CountDownTimer, dropping a Handler callback, restoring a friendlier notification string. Checked that they fail without the fixes, not just that they pass with them: restoring the "disconnects in 5 minutes" wording and moving releaseSession() out of disconnect() both turn them red. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-10-17 16:37:41 +03:00