* refactor: remove device Pairing feature entirely (issue #645) - Delete Pairing.kt model + pairing API endpoints (get/approve/revoke/clear) - Delete PairingScreen/PairingViewModel + PairingCodeEntryScreen/ViewModel - Remove NavKeys, ScreenRegistry drawer entry, Navigation.kt entry + Landing pairing button - Remove pairing string resources (en + ko); keep connect_* config-parse strings - Keep Telegram onboarding pairing_id flow (separate concept, per issue) - Fix related doc comments + remaining test reference * test: fix racy CONNECTED read in gated-mode WS test (issue #635 test) testGatedMode_attemptsTicketFetchWithoutBareCookie asserted CONNECTED immediately after the server-side onOpen latch fired, racing the client handshake (WsListenerImpl sets CONNECTED on receipt of the 101). Await the real status transition via connectionStatus.first{==CONNECTED} like the other connect tests do. No product behavior changed. --------- Co-authored-by: M57 <Hy4ri@users.noreply.github.com>
This commit is contained in:
1 parent
e44a53366b
commit
a62bc7e16c
19 files changed
+13
-892
No files matched your search
@@ -542,6 +542,15 @@ class HermesWsClientTest {
|
||||
"Gated WS ticket fetch should be attempted even without a bare cookie",
|
||||
connectLatch.await(5, TimeUnit.SECONDS),
|
||||
)
|
||||
// The server-side onOpen latch fires a hair before the client receives
|
||||
// the 101 handshake and WsListenerImpl sets CONNECTED — await the real
|
||||
// status transition (as every other connect test does) instead of a
|
||||
// racy read that can observe CONNECTING.
|
||||
runBlocking {
|
||||
withTimeout(5000) {
|
||||
HermesWsClient.connectionStatus.first { it == ConnectionStatus.CONNECTED }
|
||||
}
|
||||
}
|
||||
assertEquals(ConnectionStatus.CONNECTED, HermesWsClient.connectionStatus.value)
|
||||
|
||||
ticketServer.shutdown()
|
||||
|
||||
Reference in new issue
Block a user