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

Compare with Current View Page History

Version 1 Next »


1. Ticket Details

FieldDescription
Ticket IDAMM-1889
SeverityBUG
CategoryBug
Affected Module / FeatureECD

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)

ActionOwnerTarget DateStatus

  • 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.



Developer

 

Completed


5. Preventive Actions (To prevent recurrence)

ActionOwnerTarget DateStatus

  • Include session expiry test cases in regression suite.

QA


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

Reviewed ByDateRemarks




  • No labels