BUG: Folder loading error shows generic message, spams repeatedly, and retriggers on every window focus and restore

[g-k-s-03]

Is there an existing issue for this?

I have searched the existing issues and found no duplicate.

What happened?

I was testing PictoPy on Windows and noticed something
really frustrating in Settings → Folder Management. Every
time I switched back to the app from another window, an
error dialog popped up. I kept closing it but it kept
coming back. I decided to dig into why this was happening
and ended up finding the root cause goes deeper than just
a UI issue.

---

The Problem

When the folder list fails to load, the app shows a
generic dialog that just says:

"An error occurred. Please try again."

But that's not even the real problem — it's just a symptom.
The actual error happening underneath is:

"Internal server error - Unable to retrieve folders:
no such column: f.indexing_status"

This happens because migration_009_add_indexing_status.py
exists in the codebase but the migration runner in
backend/app/database.py only applies migrations on
fresh installs. If you already had PictoPy installed and
upgraded, your database never gets the new column — so
every folder query fails silently.

On top of that, three things in the frontend make the
experience much worse than it needs to be:

1. The real error is hidden
The actual error message from the backend exists in the
code but gets thrown away before it reaches the user.
useFolderOperations.tsx never passes error: foldersQuery.error
into useMutationFeedback, so you always see the same
generic text no matter what actually went wrong.

Interestingly, the same file handles this correctly for
enable AI tagging, disable AI tagging, and delete folder —
it was just missed for the folder loading query.

2. The dialog spams every second
Because the query polls every 1000ms during AI tagging
and there's no deduplication in the feedback hook, the
error dialog reopens every second indefinitely. Closing
it does nothing — it comes straight back.

3. Switching apps triggers it instantly
Even without AI tagging running, switching away from
PictoPy and coming back immediately fires a new folder
fetch. If that fetch fails, the dialog appears right away.
This happens because foldersQuery is missing
refetchOnWindowFocus: false — a flag that taggingStatusQuery
right next to it in the same file already has set correctly.

---

Steps to Reproduce

1. Install PictoPy on top of an existing older installation
2. Open PictoPy → Settings → Folder Management
3. Switch to any other app (Chrome, VS Code, anything)
4. Switch back to PictoPy
5. Error dialog appears immediately
6. Close it — it comes back every second
7. The dialog always shows a generic message with no
   useful information about what went wrong

---

Expected Behavior

• The real backend error should be shown so users know
  what actually went wrong
• The dialog should appear once, not spam every second
• Switching back to PictoPy should not immediately
  trigger a fresh network request
• Existing users upgrading from older versions should
  not hit database column errors

---

The Fix

The root cause is the migration runner — fixing that
stops the backend error entirely. The frontend fixes
ensure that even if any future backend error occurs,
it's shown properly and doesn't spam the user.

Backend fix (backend/app/database.py)
Update the migration runner to check and apply all
pending migrations on every startup, not just on fresh
installs. Existing data is untouched — the migration
only adds the missing column.

Frontend fixes (useFolderOperations.tsx and useMutationFeedback.tsx)

• Pass the real error through so users see what actually went wrong
• Pause polling when the query is in a persistent error state
• Add refetchOnWindowFocus: false matching the sibling query
• Add a dedupe guard so the same dialog never reopens while already visible

---

Impact

This affects every user who upgraded PictoPy from an
older version rather than doing a fresh install. The
spamming dialog and window-focus trigger affect all
users regardless of how they installed it.

Confirmed on the official v1.3.0-alpha Windows release.

---

Demo Video

bug.2.1.mp4

---

I agree to follow this project's Code of Conduct

[github-actions]

👋 Thanks for opening this issue! The maintainers will review it shortly. Till then, do not open any PR. This is a strict rule we like to follow around here :)

[github-actions]

⚠️ Potential Duplicate Issue (Semantic Match)

This issue appears semantically similar to the following issues in AOSSIE-Org/PictoPy:

1. BUG: UI flicker occurs for missing or invalid image paths (BUG: UI flicker occurs for missing or invalid image paths #1184, open)
   BUG: UI flicker occurs for missing or invalid image paths #1184
   Similarity: 57.3%

2. BUG: Settings page is slow while loading folder status (BUG: Settings page is slow while loading folder status #876, open)
   BUG: Settings page is slow while loading folder status #876
   Similarity: 56.8%

3. BUG : Infinite Stream of Folder Status Requests When AI Tagging Is Enabled (BUG : Infinite Stream of Folder Status Requests When AI Tagging Is Enabled #612, open)
   BUG : Infinite Stream of Folder Status Requests When AI Tagging Is Enabled #612
   Similarity: 55.7%

Please review before proceeding.

[g-k-s-03]

@rohan-pandeyy i wna to work on this issue

[hritikkumar07]

Hi @rohan-pandeyy , i want to work on this issue , assign me to this
This bug has three independent root causes in the same two files, so I'd tackle them as three small, isolated changes rather than one large refactor - easier to review and bisect if something regresses.

1. Surface the real error message

In useFolderOperations.tsx (lines 51–56), useMutationFeedback is called for the folders query without passing the actual error object, so it always falls back to the generic string. Fix:

ts
useMutationFeedback({
// ...existing fields
error: foldersQuery.error, // was missing
});

Since useQueryExtension.ts:112 already computes foldersQuery.errorMessage from the raw error, either pass foldersQuery.error (if useMutationFeedback expects the raw error and derives the message itself) or pass foldersQuery.errorMessage directly if it expects a string — worth checking useMutationFeedback's prop type before picking one, so the fix is consistent with how the other three operations (enable tagging, disable tagging, delete folder) already do it.

2. Stop the dialog from reopening every second

Two contributing factors here:

refetchInterval: 1000 keeps polling regardless of failure state.
TanStack Query returns a new error object reference on each failed attempt, and useMutationFeedback.tsx:118–135 has no guard against re-dispatching for a "new" error that's actually the same failure.

Two complementary fixes:

In the query config, make the interval back off or pause on persistent failure, e.g. refetchInterval: (query) => query.state.errorUpdateCount > 0 ? false : 1000, or use retry/refetchIntervalInBackground settings to stop hammering a known-broken backend.
In useMutationFeedback, dedupe by comparing something stable (error message/code, or a ref tracking "already shown for this failure streak") rather than object identity, so a dismissed dialog doesn't reopen until the error actually changes or clears.

3. Stop refetching on every window focus/restore

foldersQuery is missing the same flags taggingStatusQuery already has:

ts
const foldersQuery = useQuery({
// ...
staleTime: 1000,
refetchOnWindowFocus: false,
retryOnMount: false,
});

This alone should fix Way 3 in the repro steps.

Suggested order of work / commits

Fix #3 first (smallest, isolated, no side effects on other logic) — quick win.
Fix #1 (message plumbing) — also isolated, easy to verify visually.
Fix #2 last, since it touches both the query config and the dedupe logic and is easiest to test once #3 removes the focus-triggered noise.

Testing notes for the PR

Repro Way 1: trigger a backend failure and confirm the dialog shows the real message, not the generic one.
Repro Way 2: enable AI tagging on an indexing folder, force backend failure, confirm the dialog appears once and doesn't reopen every second.
Repro Way 3: switch away/back and minimize/restore, confirm no immediate refetch/dialog when data is fresh.

[g-k-s-03]

@hritikkumar07 i am currently working on this issue i have raised it and am waiting for the mentor to assign it @rohan-pandeyy can you assign this issue to me

[g-k-s-03]

@rohan-pandeyy thanks for assigning

[g-k-s-03]

@rohan-pandeyy While testing I found the root cause goes
deeper than the frontend.

The actual backend error is:

no such column: f.indexing_status

migration_009_add_indexing_status.py exists but the
migration runner in database.py only applies migrations
on fresh installs — existing databases from older versions
never get the new column.

[rohan-pandeyy]

The actual backend error is:

no such column: f.indexing_status

migration_009_add_indexing_status.py exists but the
migration runner in database.py only applies migrations
on fresh installs — existing databases from older versions
never get the new column.

Let's discuss this in today's (27 Sept) PictoPy Weekly Meet at 2:30 PM IST.

[g-k-s-03]

@rohan-pandeyy I will try my best to join this week's meeting, however due to some urgent work I cannot confirm my availability at that time. If I am unable to make it, I will definitely attend the next meeting and we can discuss the issue then. Apologies for the uncertainty.