Offer the log from the login screen, where failures were undebuggable - #197
Merged
Merged
Conversation
The error report page - the one screen that can produce a log - was reachable from the map and the device list and from nowhere else. So a sign-in failure, the failure most worth diagnosing and the one a new user is most likely to meet, could hand them nothing. Their options were adb on a second machine or nothing, which in practice means the report arrives as "it does not work". An `Export logs` button now sits in the error box under the failure message and opens the report page on the failure that is showing. It is a separate activity, so closing it comes straight back with the error still up and the typed Apple ID still there - looking at the log costs nothing. The body text is its own string rather than the export one. A sign-in can fail because Apple declined, which is worth waiting out rather than reporting, and the page says so before it asks for a report - the distinction #177 drew on the screen, carried through to the page behind it. `rootOf` moves to `ErrorReportActivity` beside `describe`, because every caller of that needs it first and for a reason easy to miss: Rx wraps what a `map` throws, so describing the error as it arrives puts "RuntimeException" on the page and buries the sentence the reporter needs. Two screens keeping their own copy is two reports of one bug looking like two. Two tests: that a failed sign-in opens the page with the cause carried through - asserted on the extra, not merely on the component, since an intent opening a blank report would pass that - and that the button is not offered before anything has failed.
parawanderer
had a problem deploying
to
Android Build
September 13, 2026 15:37 — with 
GitHub Actions
Failure
GitHub Actions
Failure
The report opened with `cause=unknown`. The error was displayed by the login subscriber's own inline copy of showLoginFailure - the same five steps written out again - which never recorded the failure, so there was nothing for the Export logs button to describe. Deduplicated rather than patched: the copy existed before this change and drifted the moment showLoginFailure grew a sixth step. One path now, and a second one cannot silently skip it. Worth noting the test caught this only because it asserts on EXTRA_CAUSE rather than on the component. An intent check that just confirmed the right activity opened would have passed against a report page that named nothing.
This was referenced Sep 13, 2026
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The error report page — the only screen that can produce a log — was reachable from the map and the device list and from nowhere else. So a sign-in failure, the failure most worth diagnosing and the one a new user is most likely to meet, could hand them nothing. Their options were adb on a second machine, or nothing. In practice that means the report arrives as "it does not work".
Today made the case: every sign-in in the project failed for two weeks, and no user could produce evidence of it from the app.
What this adds
An Export logs button in the error box, under the failure message, opening the report page on the failure that is showing. It is a separate activity, so closing it returns to the login screen with the error still up and the typed Apple ID still there — looking at the log costs nothing.
The body text is its own string rather than the export one. A sign-in can fail because Apple declined, which is worth waiting out rather than reporting, and the page says so before it asks for a report — the distinction #177 drew on screen, carried through to the page behind it.
Also
rootOfmoves toErrorReportActivitybesidedescribe. Every caller ofdescribeneeds it first, for a reason that is easy to miss: Rx wraps what amapthrows, so describing the error as it arrives putsRuntimeExceptionon the page and buries the sentence the reporter needs. Two screens keeping their own copy is two reports of one bug looking like two.Tests
EXTRA_CAUSE, not merely on the component, since an intent opening a blank report would pass thatBoth strings added in all ten locales;
add_strings.py --checkpasses at 373.