CSV import of entityreferences partially broken

When trying to import attached csv file something peculiar happens. It contains rows with on each row an unique key (sleutel) for this import. and also an id which is a reference to a previous record ( dad). This is an hierarchical text with a main entry, which has chapter, which have sections, which have subsections.

During import the first 50 items don't get their references set. I suspect because the previous records have not been fully processed (so entities referred to do not exist yet.) But after every 50 records they apparently do exist and references are created. The entityreference are created using the EFQ finder tamper.

For example item with sleutel 148 is a chapter with 7 sections (sleutel 149..155 ) which each have 148 as their dad. Items 149 and 150 do not get their entityreference field filled with a value. But 151 till 155 are correctly referencing their dad (148)
Another example chapter 148 and 156 both have 120 as their dad. But 148 isn't filled, however 156 (which comes after the magic 50 boundary) has the correct value!

Steps to reproduce:
- Create a content type artikel, with an entityreference field field_parent (this will reference the entity EFQ from using 'dad') and a integer field field_filemaker_id (this will contain 'sleutel' the unique id from filemaker export)
- import feeds importer and feeds tamper which are attached as files
- import the csv file (remove .txt from file)

Expected behaviour:
All rows are created as 'Artikel' and have their entityreferences pointing to their 'dad's

Observed:
Only Artikels whose dads where imported before the last multiple of 50 rows are correctly linked to their dads. The rest of the Artikels' entityreferences are empty.

This file is a subset of a larger file and smaller than a 100 lines. But these symptoms occur after every multiple of 50 rows. I have seen this number pop up on two other issues with feeds tamper plugins. I have linked them to this issue.
A subsequent import works fine, but it is a much preferred solution to have the end users only have to import once of course.
And Intuitively this should work I think.