View Source

1. Ticket Details

Field	Description
Ticket ID	AMM-1889
Severity	BUG
Category	Bug
Affected Module / Feature	ECD

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)

Action	Owner	Target Date	Status
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	08 Oct 2025	Completed

5. Preventive Actions (To prevent recurrence)

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