[BUG] Re-inserting existing triples yields duplicate triples + assert/retract churn; upsert of existing triples registers no new transaction

[aaj3f]

Source: Fluree Solo internal QA (surfaced via Solo, appears engine-level)
Reporter: Laurent Bégin
Reported: 2026-06-25
Severity: Critical (data integrity)

Summary

Re-inserting the same triples leaves the KG with duplicate triples, and the transaction history shows an assert / assert / retract churn on those triples. Separately, upsert of existing triples registers no new transaction while insert does (re-asserting existing triples) — likely the same underlying mechanism.

Environment

Solo stack lbegin-test.fluree-emea (Radio Canada / CBC, KG05), which uses fluree-db-api. Surfaced through the Solo Data/Model UI.

Symptoms

1. Duplicate triples. After multiple inserts of the same triples, an instance ends up with duplicated object values — e.g. "Québec (province)" shows property générique (publishing#BT) with the same object IRI b32e4947-… repeated ~16×, and groupe (t3#inGroup) values repeated many times.
2. Retract churn in history. Transaction t:476 (42 changes) shows a repeating assert / assert / retract pattern per value (e.g. générique +,+,−; each groupe value +,+,−).
3. Not reproducible with a single triple. Laurent could not reproduce by inserting the same single triple repeatedly — only with multi-triple inserts.
4. Upsert vs insert asymmetry (related question). Upserts of existing triples do not register as new transactions (the API returns the last transaction info); inserts do register new transactions that re-assert existing triples. End result is the same (no net data change), but the transaction log / dedup behavior differs.

What we need from the DB team

• Confirm whether this is engine-level insert/novelty dedup behavior or a Solo-transact payload-construction issue (i.e. Solo emitting each triple twice).
• Clarify the expected insert vs upsert semantics for already-present triples.
• Determine why duplicates persist in the indexed/materialized view.

References

• Slack — report (fluree-internal #mr1-qa-feedback): https://fluree-internal.slack.com/archives/C0BASKBSNTS/p1782379252869899
• Slack — related upsert/insert question: https://fluree-internal.slack.com/archives/C0BASKBSNTS/p1782379136620289
• Screenshots (internal): instance duplicate values; history t:476 assert/retract pattern.

Filed in fluree/db per triage; surfaced via the Solo QA workflow (Slack channel above).