✅ Disable PhotoStructure from "failing fast"

Feature Requests
, ,
1

First, some background:

In building PhotoStructure, as I came up with error conditions, I had to decide which errors should be “ignorable”, or “warnings,” or “fatal.” Fatal errors are when continuing on doesn’t really make a lot of sense. If the directory holding your PhotoStructure library disappears, for example, PhotoStructure can’t serve your library, so I figured it would be reasonable to shut down.

By respecting these fatal errors, I made PhotoStructure “fail fast”, which is a programming mantra from unix.

While I was helping someone with their installation today I realized that most people aren’t :nerd_face: always tailing their logs in a background terminal (like I am during development).

They spin up their docker container, or they double-click the desktop app, and if PhotoStructure shuts down before you ask it too, that’s not “acting cautiously” and “failing early.” To most people, I bet, “PhotoStructure crashed.”

So. That’s no good.

PhotoStructure already can collect recent errors (it’s what’s used for Sentry error reports).

What I realized this afternoon was that PhotoStructure could make those errors as obvious as possible: and it’d probably be easiest if those errors were just shown on the home page, or at least a notification to a logs page was prominent.

So: I’ll try to code this up quickly and get it into the next build.

If you have any feedback around this issue, including UX that you’ve seen that handles this well, please reply and share!

1 Like
2

I don’t have any formal programming background, so maybe I’m missing something…

But I don’t understand why you would kill the frontend unless an error made serving the frontend impossible. The frontend is what the user is interacting with (not the logs, as you pointed out). As long as the frontend is available, I agree that it should be used to display any relevant error messages that impact the core functionality of Photostructure.

In other words, I agree with your assessment. :slight_smile: Keep up the good work!

3

You’re correct. That’s the jist.

I conflated “serve something reasonable (like the contents of the library)” with “serve anything (like an error message saying what’s wrong)”.

4

Update: seems that any network glitch (if you’re storing your library on a remote volume) can cause health checks to fail and cause PhotoStructure to shut down.

That’s really not good.:triumph:

5

While the application is more stable than it used to be, I’ve still unfortunately experienced a few more “Failed to scan system volumes”-crashes since upgrading to beta.14. The reason I mention it in this thread is that I’m not very keen on reporting each one of them anymore as they continue to appear. Determining and accounting for every reason a disk might be (temporarily) unavailable separately feels like a game of whack-a-mole.

I’d much rather see the process silently retry its task a few more times at increasing time intervals, before finally showing some type of warning message (not a focus-grabbing alert box) inside the application mentioning the repeated failure to access the disk and its possible causes - without quitting the application afterwards.

6

This is implemented in v2.1.0-alpha.8 :tada:

1 Like