Say which half of an import failed, and give the rest a log worth sending

[parawanderer]

The app told four reporters their import failed. It hadn't.

Picking a zip started one Rx chain that parsed the file, committed the tags to the database,
and then went to Apple for their locations. One error handler covered all three, so a network
timeout, an expired session or a bad Anisette server — none of which are consulted while reading
a zip — all reported:

Error occurred while importing new devices. Try to restart the app and retry.

…for an import that had already succeeded and whose tags were visible in the device list.

#19 and
#26 are 34 comments of people working
that out for themselves. Three of them fixed their "import error" by changing their Anisette
server, which is the proof: nothing about Anisette is touched while parsing a file.

Three things were wrong, in order of cost:

1. It named the wrong phase. The import was done and committed.
2. The advice could not work. Restarting does not re-run a failed fetch, and the import it
   suggested retrying had succeeded.
3. It threw away the diagnosis. The real exception went to Log.e and nowhere a user could
   see it — which is why none of those reports can be attributed to a cause.

What changed

The chain is split at the commit point. Reading the zip and storing the tags is one
operation; asking Apple where they are is another, started only once the first has succeeded. A
phase marker would have fixed the message; splitting makes the wrong message impossible to write,
because there is no longer one handler that could say it.

Each half now says its own thing:

The zip could not be read	a named reason where there is one, and otherwise a page that can be reported
The tags arrived, the locations did not	"Your tags are imported" — they are on the phone and stay there — plus the real exception, Anisette named as the likely cause, and the setting that fixes it

No bug report on the fetch side, deliberately. That half fails when somebody's server is down
or a phone is on a train, and it retries by itself every minute. Inviting a report each time
would fill the tracker with weather. The bug page belongs to the half that reads the zip.

A page for a failure nobody can act on

UnhandledProtocolError and anything reaching REASON_UNKNOWN now land on a page carrying the
three things a report needs and a person otherwise has to hunt for: which build this is, which
exporter made their bundle, and the failure verbatim. Never for a rejected passcode, an account
with no tags, a network that is down, or a session wanting a code — each has advice this page
would be strictly worse than.

Get the log asks which of two things is wanted, because they are not the same thing: copy it
for pasting into the issue form's log box, or save it through the document picker to attach. It
shipped as a share sheet, which serves neither — with text and no stream, Drive and Files do not
appear as targets at all.

Both routes out of the app now clean the log

Settings → Export Logs wrote a raw logcat while the error page's copy went through the
redactor. Two answers from one app to "is my Apple ID in this file". Same rule on both now, and
the same refusal: if redaction cannot run, nothing is written rather than a raw log handed to
somebody on their way to attaching it somewhere public.

redact.py gains four rules for things only the app produces — coordinates (labelled and as bare
pairs, since the app writes %.4f,%.4f), reverse-geocoded place names, bundle passcodes, and the
phone number main.py prints when it lists second-factor methods. They live with the exporter's
rules rather than in a second redactor, because two sets of rules mean two answers and only one
of them would get maintained.

Which exporter made a bundle, in both places it is asked

The issue template asks, and the only place the answer lived was inside the export zip — a file
holding the private keys to somebody's tags, which the same template tells them in bold not to
open.

• Information screen lists every distinct producer, newest-used first. Not the most recent
  one: importing twice is ordinary, and naming one producer implies it accounts for every tag on
  the phone.
• A tag's own page says which exporter made that tag. When a report is about one tag out of
  twelve, the aggregate cannot tell you that. The row was nearly free — the page already read the
  same Import for its "Exported by" and "Exported at" rows.

Testing

JVM	WhichHalfOfAnImportFailedTest, DescribingTheBuildInALogTest, TheIssueLinkPointsSomewhereRealTest
Python	42 in test_redact.py, including the false-positive guards for the coordinate rule
Instrumented	the error page, both import halves, the dialog's two dismissal routes, the DAO, the device page, the Information screen

Every new assertion was mutation-checked. Two were decorations and are fixed:

• thesharedLogIsTheRedactedOne asserted only that a chooser opened — its own comment claimed
  otherwise. It would have stayed green while shipping an unredacted log, which is the one
  outcome here that cannot be taken back. It now asserts on the payload, and bypassing redaction
  reddens exactly the three tests that should go red.
• A coordinate false-positive guard used floats that were not adjacent, so the rule would never
  have matched them however loose it got — loosening \d{3,} to \d+ left all 41 green. Replaced
  with a case that sits on the boundary.

ImportDao gains a query and no schema change, so there is no migration.

Not verified

The Apple-facing paths are unchanged by this, but nothing here was exercised against a real
account or a real failing Anisette server — the fetch-failure dialog was driven with a fabricated
exception, not a live outage. The claim being made is about which message appears for which
failure, not about the failures themselves.

🤖 Generated with Claude Code