[Swift / Sign in] “Server unavailable” and sign-in timeout are shown as the same error message #13
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
[Swift / Sign in] “Server unavailable” and sign-in timeout are shown as the same error message
Severity: Minor
Issue ID: AU-APP · QA cases: AUTH-004 (Fail), AUTH-005 (Future build)
Date: November 3, 2026
Summary
The sign-in flow is expected to display three distinct error messages:
Invalid credentials.
Server unavailable.
Connection/sign-in timeout.
Currently, the application displays only two error states. Both an unreachable server and a server that does not respond are mapped to the same connection error banner.
As a result, users cannot distinguish between a server address/connectivity problem and a server that is reachable but not responding.
The issue affects the address-and-password sign-in flow (“Use address and password”). The OAuth flow through “Continue” was not reviewed.
Affected components:
Packages/FeatureOnboarding/Sources/OnboardingCore/SignInModel.swift
AnotherIM/Live/OnboardingClient+Live.swift
libtacky exposes two relevant event types, AuthError and ConnError. Different connection failures are currently reported as ConnError with different -message values, but the application discards the message and maps all ConnError events to the same UI state.
Environment
Item Details
Application anotherim-swift
c5fdeae, branch feat/ui-redesign, build 93libtacky 2f42a2f2 / v1.2.0-beta2
Server ejabberd 26.09 from anotherim-server b9e675d
Test client libtacky application profile (checks/tacky/test_tls_agent.tcl)
Verification libtacky test runs + source-code review of build 93
Physical device iPhone 13 Pro Max, iOS 26, build 93
Note: The application behavior has not yet been reproduced on a physical device. The application verdict is based on source-code review.
Preconditions
Existing account sign-in screen.
Network connectivity is available.
Steps to Reproduce
Test environment
Run:
SWIFT_SRC= bash setup/run_all.sh auth
This covers AUTH-003, AUTH-004, AUTH-004b, AUTH-005, AUTH-DIST, and AU-APP.
Application flow
Open the sign-in screen and select “Use address and password”, then test:
A valid JID for an account not yet added to the device, with an invalid password.
A JID on a non-existent domain or a server with a closed port.
A JID for a server that accepts a TCP connection but does not respond.
Expected Behavior
The requirements specify three distinct error messages for:
invalid credentials;
server unavailable;
connection/sign-in timeout.
Relevant QA cases: AUTH-003, AUTH-004, and AUTH-005.
Actual Behavior
libtacky provides distinguishable failure information
Run 45958488 (evidence/events_auth_45958488.txt) produced:
Invalid password:
conn -message {authentication failed: not-authorized}
Closed port:
conn -message {io: connecting to 127.0.0.1:1: Connection refused (os error 111)}
Unresolvable hostname:
conn -message {io: resolving no-such-host.invalid: … Name or service not known}
Server accepts the connection but does not respond:
conn -message {STARTTLS: no within 10s}
The timeout occurred after approximately 10.6 seconds.
The application reduces these to two UI states
In OnboardingClient+Live.swift:157-163:
.authError → .authFailed
any .connError → .connectionFailed
The original error message is not propagated.
SignInModel.swift:55-57 defines only two relevant banners: auth and connection.
At SignInModel.swift:281:
banner = verdict == .authFailed ? .auth : .connection
The screen's own timeout (timeout = 45 s at SignInModel.swift:89) also results in .connection (:268).
The result is that both “server unavailable” and “timeout” are displayed using the same connection banner:
“The server could not be reached. Check the server name and your connection.”
Reproduction Status
The application behavior is deterministic based on the reviewed source code.
AU-APP is a static source-code verification, not a runtime reproduction of the application defect.
The 2/2 test runs (45958488, 611b49f9) confirm only the libtacky event behavior.
Root Cause
The issue is established by source-code review; no device log showing the UI failure is available yet.
The relevant code path is unambiguous:
OnboardingClient+Live.swift:161-163 maps every ConnError to .connectionFailed and discards the original message.
SignInModel.swift:281 maps .connectionFailed to the .connection banner.
As a result, the application cannot distinguish an unreachable server from a timeout or other connection-level failures.
Suggested Fix
Consider preserving a connection failure category or error code from libtacky in SignInProgress, for example:
Server unavailable: connection or DNS errors such as io: connecting and io: resolving.
Timeout: errors indicating that the server did not respond, such as within.
Other connection errors: a generic fallback.
Add a third banner, for example “The server is not responding”, and handle the sign-in screen's own timeout separately.
The exact classification and implementation are left to the development team.
Verification After Fix
On an iPhone, test the address-and-password sign-in flow with:
An account not already present on the device and an invalid password.
test@no-such-host.invalid with any password.
A server that accepts the connection but does not respond.
Verify that three distinct messages are displayed. Record screenshots, UTC timestamps, and relevant diagnostics entries such as conn or conn .
Evidence and Status
Evidence:
evidence/events_auth_.txt — libtacky events.
evidence/auth_.json and evidence/run_auth_.out — test results.
evidence/SignInModel.swift_50-60_250-285.txt
evidence/OnboardingClient+Live.swift_131-170.txt
Test report:
results/2026-11-03_calls_auth_contacts.md, section 3.
Verified: libtacky events from two test runs and the relevant application source code in
c5fdeae.Not verified: the visual appearance of the banners on a physical device; the OAuth flow through “Continue”; and whether the same screen behavior applies when adding a second account.
4832765(build 95): a sign-in that gets no answer now shows "The server is not responding", separately from "The server could not be reached". It uses the ConnError text ("within"/"timeout") and the screen's own timeout.