Two rows, one ticket, different answers
The export was run twice and the files were concatenated, so some rows appear twice, identically. Those are easy: keep one.
Others appear twice with ONE field different — the same ticket id, a different priority. That is not a duplicate you can remove, because the file does not say which row is right. Picking the first, or the last, is a coin toss dressed as a rule, and whichever you pick will be wrong for some tickets.
The correct behaviour is to keep neither and raise a conflict. It feels like less progress and it is the whole difference between an import a customer can trust and one they cannot.
Example
TCK-0001,Warranty,normal,resolved # appears twice, identical -> keep one TCK-0002,Technical,high,open # and later: TCK-0002,Technical,urgent,open # same id, priority differs -> CONFLICT
Your task
Read tickets.csv and print, in this order: the count of unique tickets stored, the count of exact duplicates dropped, and then one conflict <id>: <field> line per conflicting field, sorted by ticket id.
Stuck?
Explain it
Your reviewer suggests "just take the most recent row". The file has no timestamp on the row. What do you say?
Where this goes
D3 requires exactly this behaviour, and its rubric counts a silent de-duplication as a failure even when the totals happen to look right.
Files you can open: tickets.csv
This is a teaching runtime for a subset of Python, running in your browser. Integers are exact and the errors are written in plain English, but the standard library is a small subset and anything missing is refused by name rather than approximated. Your project runs on real Python.
Press Run to see what your program does, or Check when you think it is right. Everything runs here in your browser.