Check other tables
It is possible that the functionality in question would get serious data in another table (s) and there is some record. The system, seeing that something already exists, does not record the user.
Masked error
Another possibility is that there is an error, but your test is not picking it up.
It would be interesting to look carefully at the return log of each request.
System cache
If the system has some type of cache, it may have a version of the user in memory and think that it already exists.
This scenario is rather strange, but may occur depending on how the system manages its entities. Incorrect logic using the Java JPA API can lead to this kind of problem.
Environment Confusion
There are also times when we look at the incorrect database or table.
If in doubt, check with the person in charge of the environment if there is any change. It may be that someone has set up the system to use another instance of the database server.
Lost record
Another possibility is that the user was recorded during the second test, but you could not find it because the ID or some field used in the query criteria has changed.
This is common to occur if there are fields generated automatically by the system.
Final considerations
I tried to enumerate the most common problems that occur in scenarios where there does not seem to be a reasonable explanation
However, the problem may be in the most basic misconception, such as looking at the wrong bank, as in the more "obscure" details of the system architecture.
If none of these help you, you have to work with the system developer, who can debug the exact behavior of the program. Remembering that in such situations it is essential to detail the procedure for reproducing the problem.