cs_tools Searchable Metadata Sync Failing with KeyError: 'created' — Persists After Upgrade (1.6.3 → 1.6.9)

[quaresmar]

First Stop

• I have read and agreed to the ThoughtSpot LICENSE.
• I understand that if I have a critical issue with ThoughtSpot, I should reach out to my designated Account Executive and Customer Success Manager instead of cs_tools.

Platform Configuration

Info snapshot taken on 2026-07-20 │
│ │
│ CS Tools: 1.6.9 │
│ Python Version: Python 3.9.25 (main, Jul 13 2026, 00:00:00) │
│ [GCC 11.5.0 20240719 (Red Hat 11.5.0-14)] │
│ System Info: Linux (detail: Linux-5.14.0-503.16.1.el9_5.x86_64-x86_64-with-glibc2.34) │
│ Configs Directory: /home/admin.rquaresma/.config/cs_tools │
│ Activate VirtualEnv: source "/home/admin.rquaresma/.config/cs_tools/.cs_tools/bin/activate" │
│ Platform Tags: linux-x86_64

Description

We're reaching out regarding an issue with the cs_tools searchable metadata sync to our Snowflake instance. A few weeks ago, the sync began failing consistently with the following error:

File ".../cs_tools/cli/tools/searchable/api_transformer.py", line 428, in ts_metadata_dependent
    "created": validators.ensure_datetime_is_utc.func(dependent["created"] / 1000),
KeyError: 'created'

The failure occurs in api_transformer.ts_metadata_dependent(), which assumes every dependent object returned by /api/rest/2.0/metadata/search includes a created timestamp. It appears at least one dependent object in our instance is missing that field.

We were originally on cs_tools v1.6.3. Suspecting this might be a version-specific bug, we've since upgraded incrementally through 1.6.4, 1.6.5, 1.6.6, and are currently on 1.6.9 — but the same KeyError: 'created' persists at the same line, unchanged, across all versions.

Could you help us with the following:

1. Is this a known/tracked issue on your end, and if so, is there a fix planned or already merged that we're missing?
2. Is there a way to identify which specific dependent object (and object type) is missing the created field, so we can address it directly in our ThoughtSpot instance if it's a data issue rather than a code issue?
3. Is there a recommended workaround in the meantime (e.g. excluding certain metadata types from the sync) so we can keep the pipeline running while a fix is investigated?

We're happy to share the full debug logs, our cs_tools config (redacted), or run any diagnostics on our end that would help narrow this down.

Thank you very much for your support.

Best regards,

Considering adding a log file.

No response

[clobato7]

For this case/issue we found a turnaround. It's independent of the syncer (reproduced identically with both Snowflake and a plain csv:// syncer).

Where: cs_tools/cli/tools/searchable/api_transformer.py, function ts_metadata_dependent():

"created":  validators.ensure_datetime_is_utc.func(dependent["created"] / 1000),
"modified": validators.ensure_datetime_is_utc.func(dependent["modified"] / 1000),

Every other field in that dict (description, object_subtype, is_verified...) uses .get(...), but created/modified use direct key access, so any dependent object missing that key crashes the whole searchable metadata run.

Why it happens: in my org, 84 of 848 FEEDBACK dependent objects (subtypes BUSINESS_TERM/REFERENCE_QUESTION) come back from metadata/search (include_dependent_objects=True) without a created key at all, modified is always present. No other object_type is affected. The affected records all carry "contentUpgradeId": "OBJECT_PUBLISHING_OWNER_ORG_MIGRATION", suggesting they lost their creation timestamp during an org-publishing migration on the ThoughtSpot side, likely a data inconsistency upstream that cs_tools isn't tolerant of.

Suggested fix:

"created":  validators.ensure_datetime_is_utc.func(dependent["created"] / 1000) if dependent.get("created") else None,
"modified": validators.ensure_datetime_is_utc.func(dependent["modified"] / 1000) if dependent.get("modified") else None,

...and make DependentObject.created/.modified Optional[dt.datetime] in models.py.

I confirmed this locally (patched, logged the offending records, reran against both syncers successfully).