Bugscope v0.18.1 — feedback from testing (extension filter, .deb packaging, isolated nodes)

[M0nkeyFl0wer]

Tested the v0.18.1 release binaries on Linux (Ubuntu, x86_64) — currently the latest
bugscope release. AppImage works well and opens graphs across several DB vintages cleanly.
Three issues worth fixing, plus two smaller notes and one open question. Everything below
was reproduced on copies of real databases; nothing touched a production store, and
findings #1 and #3 were additionally reproduced live in the GUI on a real X display (not
headless).

---

1. The picker only accepts .lbdb, so a database created by following the docs is invisible

The UI filters/validates by a hard-coded .lbdb extension in three separate places — auto-scan,
CLI argument, and the in-app "+Add" browser:

• scan_for_databases — if ext == "lbdb" (src-tauri/src/lib.rs:218)
• database_info_from_path — != Some("lbdb") → "Only .lbdb files are supported" (lib.rs:267)
• the "+Add" file browser — name.ends_with(".lbdb") (lib.rs:1772)

The catch is that .lbdb isn't the extension the documentation tells users to create. The
quickstart at docs.ladybugdb.com/get-started uses example.lbug throughout (25 occurrences,
zero .lbdb), and the installation page uses .lbug as well. .lbdb shows up only in the
developer guide's build-from-source line (lbug foo.lbdb) and in the engine's own test helper
(TESTING_DB_FILE_NAME = "db.lbdb", test/include/test_helper/test_helper.h:25) — i.e. in
build/dev contexts, not in anything a user of the app would read.

So someone who follows the get-started guide verbatim ends up with example.lbug, opens
bugscope, and sees nothing. There's no error — through auto-scan and "+Add" the file simply
isn't listed. (The "Only .lbdb files are supported" message only ever surfaces via the
CLI-argument path.)

Repro — three byte-identical copies of one working database:

cp example.lbug example.lbdb
cp example.lbug example.ldb
sha256sum example.lbug example.lbdb example.ldb   # all three identical

Launch bugscope: only example.lbdb is listed. (Hash before opening — the file's header
bytes change once a DB is opened.)

The engine doesn't need the filter, and doesn't itself impose one:

• no constant for the main DB file's suffix — StorageConstants defines suffixes for
  sidecars only (wal, wal.checkpoint, shadow, tmp) — src/include/common/constants.h:67
• no extension check anywhere in the open path
• validation is by magic bytes: "The file is not a valid Lbug database file!"
  (src/storage/database_header.cpp:44) — an error the UI already surfaces gracefully
• the engine's own migration tool models the main file as extensionless:
  LBUG_FILE_EXTENSIONS = ["", ".wal", ".shadow"] (scripts/migrate-lbug-db.py:31)

So the whitelist isn't buying safety the engine doesn't already provide — it's just rejecting
valid databases by name.

Suggested fix: drop the extension whitelist and let Database::new() validate — it already
returns a good error for non-DB files. That makes the picker work for .lbug, .lbdb, and any
other convention at once. If a filter is still wanted in the file browser, .lbug should at
minimum be included, and it should filter the default view rather than hard-reject — a user
who explicitly picks a file has already expressed intent.

2. The .deb package is non-functional out of the box

Installing the .deb and launching gives, after ~1s:

liblbug.so.0: cannot open shared object file: No such file or directory

Root cause: the .deb bundles only usr/bin/bugscope (+ icons + .desktop) — no liblbug
— and doesn't Depends: on it, while the binary's RUNPATH is $ORIGIN/../../liblbug,
which resolves to a nonexistent path once installed under /usr/bin. So there's no way for
the loader to find liblbug.so.0.

The AppImage is unaffected (it's self-contained). Options: bundle liblbug inside the
.deb with a matching RUNPATH, add a proper Depends: on a liblbug package, or drop the
.deb from releases until it can ship its dependency.

3. Isolated (edgeless) nodes are silently dropped from the main graph view

A database with real nodes but no relationships renders as a completely empty graph. The
default view builds itself purely from an edge query —
MATCH (a)-[r]->(b) RETURN a, r, b LIMIT … (collect_edge_graph, lib.rs:1268) — and a node
only enters the scene if it's the source or target of some edge. There's no fallback to fetch
isolated nodes, so a seed/partial DB (e.g. 9 nodes, 0 edges here) looks empty and reads as
"failed to load" even though nothing is wrong.

Interestingly search_nodes and get_schema_graph do use MATCH (n), so the nodes are
reachable via search and the schema view — just not the main graph.

Confirmed this is not a subgraph/show_graphs() issue: the DB has zero named subgraphs
(show_graphs() returns empty), the 9 nodes live in the main graph, and a direct
MATCH (n) RETURN count(n) returns 9. bugscope simply never asks for them.

Suggested fix: after the edge query, if the node set is small/empty, top up with a
MATCH (n) WHERE NOT (n)--() RETURN n LIMIT … pass (or show a "N isolated nodes not shown"
hint) so an edgeless graph doesn't look broken.

---

Smaller notes

• Version display: the release tag is 0.18.1 (the bundled lbug library version), but
  the app's product version is still 0.15.1 (tauri.conf.json / Cargo.toml [package]).
  Worth bumping so the About/window version matches the release.
• No analytics in the prebuilt binary: the released build isn't compiled with
  icebug-analytics, so Leiden clustering and LLM cluster-naming are unavailable at runtime
  (logs say Leiden is disabled). If that's intentional for the default artifact, a one-line
  note in the release would save confusion.

Open question — subgraph support

Given the recommendation to store each KG as its own subgraph (CREATE GRAPH /
USE GRAPH, listed via show_graphs()): bugscope's source never issues USE GRAPH or
show_graphs() — every query (collect_edge_graph, search_nodes, get_schema_graph)
runs against the default graph context only. So a KG stored purely in a named subgraph
doesn't appear to have a path to being visualized. Is subgraph visualization intended /
on the roadmap, or is the expected workflow one-graph-per-file? A database picker that also
listed show_graphs() entries (and issued USE GRAPH on selection) would make the
subgraph-per-KG pattern usable here. (Not filing this as a bug — genuinely asking, since the
subgraph feature is new and still stabilizing.)

What worked well

• AppImage launches and renders cleanly.
• Forward compatibility is solid: the 0.18.1 build opened graphs written by older LadybugDB
  versions (incl. a pre-0.17.1 store) without issue.
• Error handling is graceful: a missing file gives "File not found"; a garbage/non-DB file
  gives a clean error and no crash.

Happy to provide logs or test any fixes.

[adsharma]

@aheev: when opened from launcher, bugscope crashes without any error msg when liblbug is not present