OPC UA extractor: setting cognite.metadata-targets.clean.space silently disables classic asset creation despite clean.assets: true — intended?

Question

We hit an undocumented behavior of the OPC UA extractor (version 2.38.0, Docker) that we'd like to confirm.

Setup: cognite.metadata-targets.clean with assets: true, timeseries: true, relationships: true, plus extraction.update fully enabled. This had been running fine for months — classic asset hierarchy plus classic time series.

What we did: we added the GA Core Data Model space option to the same clean block:

metadata-targets:
  clean:
    assets: true
    timeseries: true
    relationships: true
    space: "<our-instance-space>"

What we observed:

As documented, time series switched to CogniteExtractorTimeSeries instances in the space, with datapoints available via instanceId.
Not documented: classic asset creation stopped entirely, even though clean.assets: true was still set. We verified this by deleting the extractor-managed asset hierarchy and restarting the extractor: after a full startup browse, no assets were recreated — no error, no failure run on the extraction pipeline, nothing in the space either (the docs state only CogniteTimeSeries is supported, so no CogniteAssets — also confirmed).
Removing only the space line and restarting immediately recreated the full classic asset hierarchy (all assets, correct parents) and re-linked the existing classic time series.

So with clean.space set, the extractor writes CDM time series but no asset context anywhere — the assets: true flag is silently ignored.

Questions:

Is disabling classic asset creation when clean.space is set intended behavior? If so, could this be stated in the clean.assets/clean.space documentation? A warning at startup would also help.
What is the recommended way to keep hierarchy context when using clean.space — is CogniteAsset support on the roadmap, or is the data-models (alpha) target the only option today?

APSHANKAR Sagar · Answer

A follow-up with more precise findings on the time series side, after verifying against both APIs (same extractor, 2.38.0):

clean.space does not migrate the time series — it creates a parallel, unlinked one per tag, and routes datapoints exclusively.

Concretely, for one and the same external-id string we now have two separate TS resources:

the pre-existing classic TS: has the externalId, instanceId = null;
the new instance-backed TS: different internal id, externalId = null in the TimeSeries API, addressable only via instanceId (space + externalId-as-node-id). Nothing links it to the classic one.

Datapoint routing is exclusive and follows the config atomically:

While space was set (4 days in our case): datapoints were written only to the instance-backed TS; all our classic TS received exactly zero points from the restart onward.
After removing space: classic TS resumed immediately; the instance-backed TS froze at that moment.

Net effect: every tag now carries two disjoint histories — the classic TS has a 4-day hole, and the instance TS holds exactly those 4 days. The docs' wording ("The Time Series data will also be available from the CDF TimeSeries API using the 'instanceId'") reads as one dataset reachable two ways, which is not what happens when a classic TS with the same externalId already exists.

This raises one more question in addition to the asset one: is there a supported migration path that keeps a single continuous history when enabling clean.space on a brownfield deployment — e.g. linking the existing classic TS to the new instance (à la pendingInstanceId) instead of creating a parallel TS? Without that, enabling the CDM output on an existing site means either splitting history or manually copying datapoints between resources.

Sign up

Welcome to Cognite Hub