u32i64 / readlogs Goto Github PK

Copying is technically already possible, but would require a very long manual selection. A button to copy / download the text would probably be better.

Ideally, this would not make any network requests, since the plain text is already available locally.

• Copy
• Download (implemented in d440da1)

The log level:

https://github.com/u32i64/readlogs/blob/c68e572907f4dd318088d3d72bcc82d4effc8f01/src/parsers/android.rs#L169

should probably be "pre"-parsed via nom first, similar to:

https://github.com/u32i64/readlogs/blob/c68e572907f4dd318088d3d72bcc82d4effc8f01/src/parsers/ios.rs#L24-L25

https://github.com/u32i64/readlogs/blob/c68e572907f4dd318088d3d72bcc82d4effc8f01/src/parsers/desktop.rs#L39-L46

in order to avoid a panic in case it's not a valid log level.

The problem itself may be slightly out of scope for this project, but still there are a few things that could make the experience better:

• Show some kind of modal when pressing on a log entry (there, show details with no horizontal scrolling, only vertical).
• Hide some columns as an option.
• Wrap log lines in the table.
• What else?

As a starting point, some of these features could just depend on the existing "Expand UI" / "Collapse UI" toggle.

It seems like it is useful to be able to access the file picker quickly, but it being at the very top feels clunky because it takes up a lot of vertical space. Maybe it should instead:

• Be a simple <select> element;
• Be accessible via some popup/popover.

Implement a "dark" appearance:

• Match the system appearance via the @media-query;
• Maybe also add an option: system/light/dark.

If parsing fails:

• Show the raw/plaintext file content in the Raw tab.
  • Consequently, remove the "input" from the error message linked below.
• If it's due to the remainder not being empty, show at least what's been parsed successfully (with a notice that it's not complete).
  • Consequently, maybe remove the "output" from the error message linked below (although having access to the debug representation of it may be useful, maybe it should be shown in the Raw tab instead).
• If some of the files (in case of Signal iOS) parsed successfully while others didn't, show at least those that parsed successfully. Indicate that other files could not be parsed (per-file errors).
  • Indicate in UI which files were parsed and which weren't.
  • If only some filenames couldn't be parsed, still show the files that parsed successfully.

https://github.com/u32i64/readlogs/blob/6267b116ed5f3f6a6349f5c3d514ba8908c8984e/src/parsers/mod.rs#L82-L88

(Edit: the error format has changed and the "input"/"output" values aren't currently shown in any case. However, it may be useful to show "output" in the case mentioned above.)

Highlight the text that matched the search string (e.g. so it's easier to see what caused a log entry to be included in the results).

It may be useful to allow viewing multiple debug logs at once, for example to:

1. View logs from primary and linked devices side-by-side (with alignment by timestamps) to more easily understand the overall picture;
2. Compare subsequently uploaded debug logs to see what the difference is (which log lines were added, which information changed).

Due to Logcat entries not including the year, it's currently assumed to be the current year:

https://github.com/u32i64/readlogs/blob/c68e572907f4dd318088d3d72bcc82d4effc8f01/src/parsers/android.rs#L263

That's a problem in a few edge cases:

• If the log spans multiple years (e.g. December 31 to January 1)—the year for each entry should be guessed separately;
• If, for example, the log was taken on December 31 but viewed next year on January 1—perhaps it'd be better to get the year from the timestamp in the information section.

Maybe it's better to remove the year altogether, so that the app doesn't show wrong information. In that case, creating a date object should probably use a hardcoded year that includes February 29 (are there any other considerations that need to be made?), and after converting it to a string, remove the year.

Signal Android/Desktop

The file is gzip-ped plain text. The worker alters the response to indicate this; presumably, Cloudflare then picks the best compression to deliver the response to your browser (e.g. brotli). The browser uncompresses the response and provides it to the app in plain text.

So all compression work is done by Cloudflare and the browser; neither the worker itself nor the app.

IIRC CF only tries compression for a fixed amount of time. If it takes to long or the file isn't smaller the compression is aborted.
As the logs are already highly compressed CF won't touch it. The compression might still apply to the headers but I'm not to sure about that.

Also judging from the CF support article there is a list of mime-types they compress and who'd guess application/gzip isn't one of them.

This can be confirmed when having a look at the request in the networks tab as no header like content-encoding | br is applied to it.

I suggest the point 2 being unified into roughly what the ios text says

Parse the timestamps that Signal Android and Signal Desktop logs provide in the Time key and show them like UTC log timestamps are shown.

Signal iOS debug log files don't contain dedicated information sections, but it may be useful to automatically "find" the log lines about remote config, startup, etc. with the latest timestamps and show them in the information tab (perhaps, across all files, then indicating that the information tab does not change based on switching of files).

Something like 7f763c4 would significantly improve the speed of Cloudflare Pages builds, but it fails due to this:

./trunk: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./trunk)

(and hence that change was reverted for now in 360cee2).

Is there a way to make that binary work (for what it's worth, it does work in GitHub Actions), or would a special binary be needed for Cloudflare Pages' environment?

Edit: similar issue has been reported in:

• trunk-rs/trunk#169