View Source

1. Ticket Details

Field	Description
Ticket ID	AMM-1867
Severity	Blocker
Category	Bug
Affected Module / Feature	FLW(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)

Action	Owner	Target Date	Status
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	06 Aug 2025	Completed

5. Preventive Actions (To prevent recurrence)

Action	Owner	Target Date	Status
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 By	Date	Remarks