Check other tables
It is possible that the functionality in question will record data in another (s) table(s) and there will be some record. The system, seeing that something already exists, does not record the user.
Error "masked"
Another possibility is an error is occurring, but your test is not picking this up.
It would be interesting to carefully look at the return log of each request.
System cache
If the system has some kind of cache, it might have a user version in memory and think it already exists.
This is a very strange scenario, but it can occur depending on how the system manages its entities. Incorrect logic using the Java JPA API can lead to this type of problem.
Confusion of environment
It also occurs sometimes to look at the database or incorrect table.
When in doubt, check with the environmental officer if there has been any change. It may be that someone has configured the system to use another instance of the database server.
Record "lost"
Another possibility is that the user was saved during the second test, but you did not find it because the ID or some field used in the query criteria changed.
This is common if there are fields automatically generated by the system.
Final considerations
I tried to enumerate above the most common problems that occur in scenarios where there seems to be no reasonable explanation
However, the problem may be both in the most basic misconception, such as looking at the wrong bank, and in the more "obscure" details of the system architecture.
If none of this helps you, it remains to do a job in conjunction with the system developer, who can debug the exact behavior of the program. Recalling that in situations like this it is essential to detail well the procedure for reproduction of the problem.
the table this auto-increment? because if you are making an Insert passing the value of pk, it only inserts once after the duplicity error and does not insert the repeat.
– SneepS NinjA