The users connected to the WASDI admin account, started receiving an e-mail few days ago:
"Confirmation failed: ***@****.*** is in kc but could not be added to wasdi DB"
where the mentioned user e-mail was my WASDI account.
After some investigation I found the that the e-mail was sent when accessing a ws on the computational node in the TEST environment.
It turned out to be an issue with mongo db on the local node, refusing the connection.
Here is the chain of calls which led to the email being sent (some detail in the logs were hidden on purpose):
2023-12-21T13:21:26.256: Wasdi.getUserFromSession: the session is valid but the user does not exists, add it
2023-12-21T13:21:26.256: AuthResource.userRegistration
2023-12-21T13:21:26.257: AuthResource.userRegistration: checking if *@**. is already in wasdi
2023-12-21T13:21:56.258: UserRepository.getUser : error - com.mongodb.MongoTimeoutException: Timed out after 30000 ms while waiting to connect. Client view of cluster state is {type=UNKNOWN, servers=[{address=*****, type=UNKNOWN, state=CONNECTING, exception={com.mongodb.MongoSocketOpenException: Exception opening socket}, caused by {java.net.ConnectException: Connection refused (Connection refused)}}]
2023-12-21T13:21:56.258: AuthResource.userRegistration: .@.* is a new user
2023-12-21T13:21:56.258: AuthResource.userRegistration: m_oKeycloakService is NULL!! Creating it...
2023-12-21T13:21:56.258: KeycloakService.getToken: about to get token: [... more logs here .....]
2023-12-21T13:21:56.271: HttpUtils.httpPost: Sending 'POST' request to URL : [.... more logs here.... ]
2023-12-21T13:21:56.279: HttpUtils.httpPost: Response Code : 200
2023-12-21T13:21:56.280: KeycloakService.getKeycloakAdminCliToken: admin token obtained :-)
2023-12-21T13:21:56.280: KeycloakService.getUserData: about to GET to [.... more logs here.... ]
2023-12-21T13:21:56.280: HttpUtils.httpGet: Sending 'GET' request to URL : [.... more logs here.... ]
2023-12-21T13:21:56.294: HttpUtils.httpGet: Response Code : 200
2023-12-21T13:21:56.294: KeycloakService.getUserData: user data: [.... more logs here.... ]
2023-12-21T13:21:56.294: AuthResource.userRegistration: user details parsed
2023-12-21T13:22:26.295: UserRepository.insertUser : error - com.mongodb.MongoTimeoutException: Timed out after 30000 ms while waiting to connect. Client view of cluster state is {type=UNKNOWN, servers=[{address=**, type=UNKNOWN, state=CONNECTING, exception={com.mongodb.MongoSocketOpenException: Exception opening socket}, caused by {java.net.ConnectException: Connection refused (Connection refused)}}]
2023-12-21T13:22:26.295: AuthResource.userRegistration: could not insert new user .@***. in DB, aborting
2023-12-21T13:22:26.295: AuthResource.notifyNewUserInWasdi
2023-12-21T13:22:26.295: WasdiResource.sendEmail: send notification
2023-12-21T13:22:26.403: WasdiResource.sendEmail: notification sent with result [.... more logs here.... ]
@wasdi-sysadmin-br solved the issue, but ideally, in the code we could have managed better the error with mongo the first time that the connection was refused and stop proceeding with the registration of the new user.
We could consider to handle this kind of issues with mongo differently (right now we just catch and log the exception and return a null value) and maybe send a more meaningful e-mail to the admins to report the issue (it would be useful to react quickly when the same issues happens in prod).
The users connected to the WASDI admin account, started receiving an e-mail few days ago:
"Confirmation failed: ***@****.*** is in kc but could not be added to wasdi DB"where the mentioned user e-mail was my WASDI account.
After some investigation I found the that the e-mail was sent when accessing a ws on the computational node in the TEST environment.
It turned out to be an issue with mongo db on the local node, refusing the connection.
Here is the chain of calls which led to the email being sent (some detail in the logs were hidden on purpose):
@wasdi-sysadmin-br solved the issue, but ideally, in the code we could have managed better the error with mongo the first time that the connection was refused and stop proceeding with the registration of the new user. We could consider to handle this kind of issues with mongo differently (right now we just catch and log the exception and return a null value) and maybe send a more meaningful e-mail to the admins to report the issue (it would be useful to react quickly when the same issues happens in prod).