Page History

...

...

2. Issue Description

• When IsAllocated becomes 0 due to a language mismatch:

  • The same Mother ID reappears on the ECD Supervisor Dashboard for allocation.

  • This happens because the dashboard logic only considers the allocation count, not the previous failed allocation reason.

• As a result:

  • Previously handled calls may be reallocated again

  • And may appear under the Associate Call Category incorrectly.
    
    
    

...

3. Root Cause Analysis (RCA)

During the call closure process, the system enforced a preferred language validation between the Associate and the Beneficiary:

• The Associate’s mapped language was validated against the Beneficiary’s preferred language.

• When a language mismatch occurred at call closure:

  • The system updated the t_mothervalidrecord table.

  • The IsAllocated flag for the corresponding Mother ID was reset to 0.

This caused the system to treat already allocated records as unallocated, allowing them to reappear on the ECD Supervisor dashboard.

Why the Issue Occurred

• The ECD Supervisor dashboard relies primarily on the IsAllocated flag to determine allocation eligibility.

• It does not distinguish between:

  • Newly unallocated records, and

  • Records reset due to validation failures during call closure.

• As a result, records with language mismatch failures re-entered the allocation flow and appeared under the Associate Call category again.

Resolution / Fix Applied

• The language validation check has been removed during the call closure process.

• This ensures that:

  • Call closure does not reset the IsAllocated flag due to language mismatch.

  • Already allocated records do not reappear for reallocation on the supervisor dashboard.

Conclusion

The issue was caused by enforcing language validation during call closure, which unintentionally reset the allocation status. By removing the language checks at the closure stage, the allocation flow remains consistent, preventing duplicate allocations and incorrect call categorization.

4. Corrective Actions (Fixes for this instance)

...

• Implement checkKeyExists in tm-api to validate the session/login key and optionally the IP. Update preHandle to call this method for requests with authorization headers and return USERID_FAILURE (5002) for invalid or missing keys, avoiding fallback to common-api. Add logging for failed validations including userId, IP, and timestamp. Test the flow to ensure invalid or missing keys are blocked and proper status codes are returned.

...

...

...

...

1. Introductory call in ecd supervisor dashboard:
   
   Image Added
2. Associate allocatiion:
   Image Added
3. Call done with language map miss with i used dhanista boro he knows assame but while call cloase choosen hindhi
   Image Added
4. Image Added
5. Because of langauge logic again back to ecd supervior
   Image Added
6. Again he can allocate to other supervisor
   Image Added
   
   
   Tables inlvoed:  Counts will taken from t_mothervalidrecord  table(this table handle all introductory call count based on isAllocated flag)  and   language map check with v_get_userlangmapping.
    t_mctsoutboundcalls   are the call history

5. Preventive Actions (To prevent recurrence)

...

• Include session expiry test cases in regression suite.

...

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

...