Differentiating origins of aspects between ingestion and API calls

Original Slack Thread

Is there is a way to differentiate the aspects getting created via ingestion or openapi
Like in ingestion we are creating entities and it’s aspects
And with openapi we are updating properties for these aspects
Is there is way to differentiate between aspects those that are created via ingestion or updated via api call?

Hmmm as far as i knowwe don’t support this - <@U03BEML16LB> could you confirm on this?

hey there! I think there should be a way for you to check this. in mysql, the column systemmetadata contains a field called runId - this field will be set when you ingest an aspect, and when you create an aspect via an API call (or from the UI etc.) it should be no-run-id-provided - I would double check this yourself but that would be one way to differentiate

This runid will be the part of MCP and MCL
Does it get changing when an MCL getting generated for this MCP?
And how this runid get assigned ?

<@U03BEML16LB> can u refer the code where in case of batch ingestion run id is getting generated.
That would be really helpful

And who is assigning this run id as per my understanding in case of batch ingestion plug-in is assigning this runid but who is assigning this default id in other cases ?

yeah you can see https://github.com/datahub-project/datahub/blob/master/metadata-io/src/main/java/com/linkedin/metadata/entity/EntityServiceImpl.java#L1154|here where our own system is default setting the run ID if there isn’t one provided. Our ingestion connectors will set a run ID if it’s coming through there but i’m not entirely sure where that gets set