Sqlite: ExportSQLTestCase.test_export_sql fails on core 6.1 (passes 6.0) — needs triage

[eduralph]

Summary

The Sqlite addon's tests/test_sqlite.py::ExportSQLTestCase::test_export_sql fails against gramps core 6.1 while passing against 6.0, in the addon × core version matrix. Surfaced during a gramps-testbed-v2 root-cause recheck of issue 8653 (the addon-unit gate previously reported only a vague "runner exited 1, no parsed failures, no matching baseline signature"; the recheck resolves that into this concrete, named failure).

Observed (addon-unit matrix)

Leg	Result
addons-source gramps60 × core 6.0	green (no failures)
addons-source gramps61 × core 6.1	fail — 1 new failure not in baseline: Sqlite.tests.test_sqlite.ExportSQLTestCase::test_export_sql

What the test does

A full round-trip through the addon (Sqlite/tests/test_sqlite.py:27-50): setUp imports example/gramps/example.gramps into a sqlite-backed DB, exportSQL(...) to /tmp/exported1.sql, opens a second sqlite DB; test_export_sql then importSQL(...) that file back. So the failure is in the export→import path against a 6.1 core, not a trivial assertion.

Not yet captured

The gate reports the baseline delta, not the underlying traceback/assertion — so the cause (exception type, which step fails) is not yet pinned. This needs triage: it could be

• a genuine Sqlite export/import regression,
• a core-6.1 API/schema interaction (it's 6.1-only), or
• baseline drift (the recorded baseline no longer matches).

Repro

From a gramps-testbed-v2 checkout with the per-version worktrees built:

CORE_VERSION=6.1 ./engine/scripts/ubuntu/run-addon-unit.sh Sqlite

(CORE_VERSION=6.0 for the passing leg, to confirm the 6.0/6.1 split.)

---

Filed on the fork because upstream gramps-project/addons-source has issues disabled (per the testbed's non-Mantis → fork-issue convention). Origin: gramps-testbed-v2 issue_8653 recheck.