Have been experiencing the same issue myself. Have not found a solution besides either removing the relationship, or disabling Incremental Refresh altogether for the table on the one-side of a One:Many relationship.

The issue occurs when a record that already exists in a historical partition is changed/updated. That triggers the record to be loaded into a new partition, and for that split-second, Power BI sees it as two (duplicate) values and kills the refresh. Adding extra deduplication steps in Power Query/SQL will not fix the issue, since it is caused when the Power BI service partitions the data. Refreshes succeed just fine locally in Power BI desktop- there are no real duplicates in the source.

Setup in my use case is a 2 year archive, with the incremental refresh period set to 3 days. It uses a static CREATEDDATETIME field for each record. Also using Detect data changes on a LASTMODIFIED field, to account for records created a while back that may be updated later on. Works like a charm for all of my tables on the Many-side of any One:Many relationships.

Ultimately, the one-sided tables are usually smaller (in theory) so the cost of disabling incremental refresh is typically not prohibitive.