"Checking what this server uses…" was also the failure state #102

2026-09-05T19:42:03Z

paulhitt commented

2026-09-05 19:42:03 +00:00

(Migrated from gitlab.com)

"Checking what this server uses…" was both the working state and the failure state.

discovered is null while the probe is in flight and after it comes back with nothing, so a relay that never answers leaves the sign-up form on that sentence forever — no error, no retry, nothing to act on.

Found by the instrumented suite on a cold-booted emulator: 9 of 10 tests failed with nav-contacts did not appear within 120000ms, and the screen dump showed the form still checking.

Why it never answered: the app was pointed at http://10.0.2.2:18810, and Android has blocked cleartext HTTP by default since API 28 — no usesCleartextTraffic, no network security config. The request never left the device. That refusal is correct and unchanged; SiteConfig already explains why defaulting to http would be the worst outcome. What was wrong is failing silently, so a self-hoster who omits the scheme gets a dead screen.

Now bounded at 15s with a distinct failure state that names the likely cause.

Also adds scripts/instrumented.sh. Two ways an on-device run silently targets production, both closed:

the suites default to live hosts when no relay is named (relay1.flamenet.io, and relay.flamenet.io for the fleet test) — the script has no default and refuses both by name
a saved emulator snapshot restores whatever the AVD last did; today that was a session signed in as fnreviewbeta against production, under a run told to use a local relay. Now always -no-snapshot-load.

It also exits 3 on a skip, because every one of these suites opens with assumeTrue(relayReachable()) and an unreachable relay otherwise produces a green build that exercised nothing.

**"Checking what this server uses…" was both the working state and the failure state.** `discovered` is null while the probe is in flight *and* after it comes back with nothing, so a relay that never answers leaves the sign-up form on that sentence forever — no error, no retry, nothing to act on. Found by the instrumented suite on a cold-booted emulator: 9 of 10 tests failed with `nav-contacts did not appear within 120000ms`, and the screen dump showed the form still checking. Why it never answered: the app was pointed at `http://10.0.2.2:18810`, and **Android has blocked cleartext HTTP by default since API 28** — no `usesCleartextTraffic`, no network security config. The request never left the device. That refusal is correct and unchanged; `SiteConfig` already explains why defaulting to http would be the worst outcome. What was wrong is failing silently, so a self-hoster who omits the scheme gets a dead screen. Now bounded at 15s with a distinct failure state that names the likely cause. Also adds `scripts/instrumented.sh`. Two ways an on-device run silently targets production, both closed: - the suites **default to live hosts** when no relay is named (`relay1.flamenet.io`, and `relay.flamenet.io` for the fleet test) — the script has no default and refuses both by name - a **saved emulator snapshot** restores whatever the AVD last did; today that was a session signed in as `fnreviewbeta` against production, under a run told to use a local relay. Now always `-no-snapshot-load`. It also exits **3** on a skip, because every one of these suites opens with `assumeTrue(relayReachable())` and an unreachable relay otherwise produces a green build that exercised nothing.

paulhitt commented

2026-09-05 19:42:31 +00:00

(Migrated from gitlab.com)

added 1 commit

1a7c2538 - Allow the test fleet in the instrumented runner, refuse only production

Compare with previous version

added 1 commit <ul><li>1a7c2538 - Allow the test fleet in the instrumented runner, refuse only production</li></ul> [Compare with previous version](/paulhitt/flamenet-messenger-android/-/merge_requests/75/diffs?diff_id=2007001113&start_sha=d8d48d8651abf37dd31e7f1c222d4b7c5ac55760)

paulhitt commented

2026-09-05 20:15:30 +00:00

(Migrated from gitlab.com)

added 1 commit

77a7f398 - The instrumented suite could not sign up, and said nothing about it

Compare with previous version

added 1 commit <ul><li>77a7f398 - The instrumented suite could not sign up, and said nothing about it</li></ul> [Compare with previous version](/paulhitt/flamenet-messenger-android/-/merge_requests/75/diffs?diff_id=2007027859&start_sha=1a7c25386df3d2ba39ad6f1e11ff8feabd253002)

paulhitt commented

2026-09-05 22:25:13 +00:00

(Migrated from gitlab.com)

mentioned in commit 518c39682b

mentioned in commit 518c39682b073071346854ffd7bdb1f143c45208

paulhitt (Migrated from gitlab.com) merged commit 518c39682b into main

2026-09-05 22:25:13 +00:00

paulhitt commented

2026-09-06 10:51:56 +00:00

(Migrated from gitlab.com)

mentioned in issue #21

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: extant2000/flamenet-messenger-android#102