Forum Discussion
Copy Data activity fails with KeyNotFoundException
That's helpful information; thank you. The Copy activity ran fine with no errors this week, so it does indeed seem likely that the issue is a transient one. I'll set the activity to 2 retries and see whether performance continues to be better for the next few eweks.
Hi akaplan1-slcc ,
Sorry for the delay response.
Yes, “Used parallel copies = 1” shows that the Copy activity was already running with minimal concurrency, so parallelism isn’t the issue.
Additionally, manually re-running the next day is different from enabling a retry on the activity. The retry policy works immediately within the same execution context, which can help resolve transient metadata issues like the KeyNotFoundException during partition overwrite. That’s why it’s recommended to set a small retry count, such as 2–3.
Since the file paths exist and no other pipeline writes to this table, the next thing to check is the stability of partition key values differences in casing, trailing spaces, special characters, or format changes can alter the physical folder name even if the values aren’t null.
Please try enabling the retry policy and check if the behaviour changes. Hope this helps. Please feel free to reach out for any further questions.
Thank you.
Thank you.
That's helpful information; thank you. The Copy activity ran fine with no errors this week, so it does indeed seem likely that the issue is a transient one. I'll set the activity to 2 retries and see whether performance continues to be better for the next few eweks.
Hi akaplan1-slcc ,
Thank you for the update. Setting 2 retries is a suitable approach for this type of transient write behaviour. Please monitor the next few runs, and if it reoccurs, share the failed run’s Activity ID and timestamp so we can review it further.
Thank you.