When attempting to assign a user to a project using the /api/v1/project/{projectname}/assign endpoint, if the username in the request has different casing than the stored username (e.g., requesting "aartigandhi-NICE" when "aartigandhi-nice" exists), the system fails with a Hibernate session error instead of properly detecting the duplicate assignment.
Error: Failed for (500): {"errorCode":5000,"message":"Unclassified error [A different object with the same identifier value was already associated with the session: [com.epam.ta.reportportal.entity.user.ProjectUser#com.epam.ta.reportportal.entity.user.ProjectUserId@6ce]]"}
This particularly affects GitHub authentication users where usernames may be submitted with varying case sensitivity.
Root cause: The duplicate check uses case-sensitive comparison while user lookup uses normalized (lowercase) comparison. When the case-sensitive check fails to detect the existing user, the system attempts to create a duplicate ProjectUser entity, causing Hibernate to throw a session conflict error due to the composite key constraint.
Expected behavior: Should return "User cannot be assigned to project twice" error
Actual behavior: Returns HTTP 500 with session error. Replicated on the portal.
Opened a PR with an attempted fix for this issue:
https://github.com/reportportal/service-api/pull/2483/files
When attempting to assign a user to a project using the /api/v1/project/{projectname}/assign endpoint, if the username in the request has different casing than the stored username (e.g., requesting "aartigandhi-NICE" when "aartigandhi-nice" exists), the system fails with a Hibernate session error instead of properly detecting the duplicate assignment.
Error: Failed for (500): {"errorCode":5000,"message":"Unclassified error [A different object with the same identifier value was already associated with the session: [com.epam.ta.reportportal.entity.user.ProjectUser#com.epam.ta.reportportal.entity.user.ProjectUserId@6ce]]"}
This particularly affects GitHub authentication users where usernames may be submitted with varying case sensitivity.
Root cause: The duplicate check uses case-sensitive comparison while user lookup uses normalized (lowercase) comparison. When the case-sensitive check fails to detect the existing user, the system attempts to create a duplicate ProjectUser entity, causing Hibernate to throw a session conflict error due to the composite key constraint.
Expected behavior: Should return "User cannot be assigned to project twice" error
Actual behavior: Returns HTTP 500 with session error. Replicated on the portal.
Opened a PR with an attempted fix for this issue:
https://github.com/reportportal/service-api/pull/2483/files