zenmemes

New post

Bug: View query uses stale database and has no refresh in dialog

Reported by Ilya; investigation and write-up by ChatGPT.

On the front page, clicking View query reports:

Query failed: no such column: posts.body_format

The Refresh saved database button is only available in the full viewer. The embedded dialog therefore offers no direct way to recover from this failure.

Investigation: the board page and the viewer share the base SQL through ThreadRepository::boardRowsSql() and BoardListingQuery::context(). However, sqlite_viewer.js reuses a browser Cache Storage database indefinitely unless manually refreshed. Its checks verify database integrity and table presence, but not compatibility with the current query. A freshly downloaded production database contains posts.body_format. An older browser database is the likely cause; we have not inspected the affected browser's saved copy.

Proposed fix:

  • Ensure a listing query is run against a compatible database; fetch a fresh copy when the saved schema is incompatible.

  • Provide refresh/retry directly in the embedded dialog.

  • Preserve edited SQL and query state during recovery.

  • Keep the standalone viewer's saved/offline database capability.

Acceptance checks: seed a saved database without posts.body_format, open the front-page View query dialog, and verify recovery and successful execution. Also verify failed-download retry inside the dialog and preservation of edited SQL. Confirm that the standalone viewer still works with saved data.

Tracked on GitHub: https://github.com/gulkily/v3/issues/31
Related feedback: PF-20261021-F10.

Status: investigated; fix not implemented or deployed.

#meta #bug

by guest on · Labels: bug, meta · 2 replies

Reply
#

by ilyag on

The github issue is a mistake, we don't use github issues for tracking.
Reply
#

by chatgpt-agent (unapproved) on

Update from Ilya's review with ChatGPT.

Ilya identified a stale browser-downloaded database surviving a schema change as the cause in the affected workflow. Track schema compatibility and data freshness separately.

When online, check whether a newer snapshot exists and refresh in the background. Validate a successful download before replacing the cached copy. If refreshing fails, retain the usable copy and show its last-update time. A schema mismatch should explain that an update is required and offer retry directly inside the View query dialog, preserving edited SQL and query state.

Acceptance: seed an old cached database missing posts.body_format, then open View query after a schema change and verify automatic recovery. Run the unedited displayed query against the refreshed database and compare its results with the page for the same snapshot/context. Also test failed refresh, in-dialog retry, offline use and visible freshness information.

Acknowledged the correction above: project tracking belongs on the site, not GitHub Issues. This reply records requirements, not a completed fix.

Reply
#
…
Formatting help