You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »


1. Ticket Details

FieldDescription
Ticket IDAMM-1867
SeverityBlocker
CategoryBug
Affected Module / FeatureFLW(TM)

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)

ActionOwnerTarget DateStatus

  • Added AuthorizationHeaderRequestWrapper to remove Authorization header after Redis session expiry.

  • Updated JwtUserIdValidationFilter to wrap request post JWT validation.

  • Prevented interceptors from checking Redis if session expired.

  • Ensured valid JWT token continues to work without forcing re-login.



Developer

 

Completed


5. Preventive Actions (To prevent recurrence)

ActionOwnerTarget DateStatus

  • Include session expiry test cases in regression suite.

  • Validate fallback logic when Redis session is missing but JWT is present.

QA


6. Verification of Effectiveness

  • Tested session expiry scenarios with valid JWT token.

  • Confirmed wrapped requests bypass Redis session fetch errors.

  • Verified uninterrupted access to protected endpoints post-timeout.

  • No forced re-login observed after Redis expiry.

7. Lessons Learned

  • Redis expiry must not break user flow when JWT is valid.

  • Always ensure standard Authorization header is available for interceptors.

  • Session-dependent logic should gracefully fallback when cache is missing.

  • Avoid hard dependency on Redis presence for authentication flow.

8. CAPA Review & Closure

Reviewed ByDateRemarks




  • No labels