1. Ticket Details

2. Issue Description

When mobile aplication sync the benficiary which vraeted by user it uses tm-api/registrar/registrarBeneficaryRegistrationNew  when doing this it thows the error 5000 contact administrator.

3. Root Cause Analysis (RCA)

Technique Used: Log/Trace Review

The preHandle method in tm-api intercepts the request and extracts the Authorization header. If the header is missing or empty, the request proceeds without validation. For other requests, it tries to validate the session key using the validator.checkKeyExists() method.

Currently, the checkKeyExists method is missing in tm-api, so the request falls back to common-api (connected to another service), which throws a generic 5000 error without proper validation.

The correct checkKeyExists method should be implemented in tm-api to validate the login key and optionally the IP address

Currently, preHandle does not correctly handle this, which results in returning 5002 status (USERID_FAILURE) from the generic error handler. The OutputResponse class maps exceptions to status codes:

• SUCCESS = 200

• GENERIC_FAILURE = 5000

• OBJECT_FAILURE = 5001

• USERID_FAILURE = 5002

• PASSWORD_FAILURE = 5003

• ...

For IEMRException, the response sets:

• statusCode = USERID_FAILURE (5002)

• status = "User login failed"

• errorMessage = <exception message>

Summary: The 5000 error occurs because the session key validation is missing in tm-api. Implementing checkKeyExists in tm-api ensures validation happens at an earlier stage, preventing fallback to common-api and returning proper error codes (like 5002) with meaningful messages.

4. Corrective Actions (Fixes for this instance)

5. Preventive Actions (To prevent recurrence)

6. Verification of Effectiveness

• Session key validation in tm-api was tested using valid and expired JWT tokens. Requests correctly return USERID_FAILURE (5002) for invalid/missing keys. Protected endpoints remain accessible for valid sessions, fallback to common-api no longer occurs, and no forced re-login is observed after Redis expiry.

7. Lessons Learned

• • Always implement critical validation logic (checkKeyExists) within the service itself to prevent fallback to external services and avoid generic errors.

  • Proper error mapping and meaningful status codes improve troubleshooting and user experience.

  • Session handling should account for expiry, Redis failures, and IP validation to maintain secure and uninterrupted access.

  • Early testing of authentication and session scenarios prevents recurrence of similar issues.

  • Logging and monitoring of failed validations are essential for quick detection and resolution of issues.

8. CAPA Review & Closure