system.tag.storeTagHistory() causing duplicate sqlth_te entries for same tag path with no structural change

Ignition
1

Ignition version: 8.1.43
Database: PostgreSQL
Module: Tag Historian (standard SQL historian)

Issue:

I am storing time-series data into Ignition's tag historian using system.tag.storeTagHistory() from a Gateway Timer Script. The values and timestamps originate from an external ERP/API source (not live tag scan-class updates) — the script fetches data on a schedule, processes it, and writes it into two memory tags using storeTagHistory.

Recently I noticed that sqlth_te contains two separate entries for the exact same tag path, with different id values — one retired, one active:

id:23 | RETIRED at <timestamp> | path:production/igu/igu 1/sealant_consumptions/filtered_sealant_consumption
id:21 | ACTIVE              | path:production/igu/igu 1/sealant_consumptions/filtered_sealant_consumption

The tag path is identical, and I have not:

  • Changed the tag's data type
  • Deleted and recreated the tag
  • Edited the tag's History configuration (Provider, Sample Mode, etc.)
  • Restarted the Gateway during a config change
  • Moved the tag to a different folder

The only operation happening repeatedly is system.tag.storeTagHistory() being called from a scheduled Gateway script, roughly every hour, writing batches of historical rows with explicit timestamps (not "now").

Questions:

  1. What internal conditions cause Ignition to retire an existing sqlth_te row and create a new one for the same tag path, beyond the documented triggers (datatype change, tag recreation, history config edit)?
  2. Can repeated calls to system.tag.storeTagHistory() with externally-sourced timestamps (not real-time system.date.now()) ever cause Ignition to treat the tag as "new" internally — for example if there's a long gap between calls, or if the Gateway restarts between calls?
  3. Is there a way to force storeTagHistory to resolve to a specific tagid rather than relying on path-based lookup against sqlth_te, to avoid this ambiguity?
  4. Are there known issues with storeTagHistory and memory tags specifically (vs. OPC tags) that could explain this re-registration behavior?

What I've tried:

  • Retiring the duplicate sqlth_te row manually via SQL and continuing to use the same tag path — this resolves the immediate issue but I'd like to understand the root cause to prevent recurrence.
  • Checked Gateway logs around the retirement timestamp — (no observations)

Any guidance on the internal logic Ignition uses to decide when a tag path "ages out" of its current sqlth_te entry would be greatly appreciated, since this is causing chart binding issues and requires manual cleanup each time it happens.