Bug: candidates based in India reverting to BOSCO as managing partner

[samschlicht]

This has happened three times now:

Sadat changed all candidates based in India to have managing partner MAP instead of BOSCO. A week or so later, MAP found that they couldn't access a candidate based in India because their managing partner was again BOSCO.

The first time, Sam assumed that a few candidates had somehow been overlooked and just amended them by direct DB edit.

The second time, Sadat noted that a candidate had reverted to BOSCO, and amended that single candidate by direct DB edit.

The third time, Sam reapplied the correct partner and noticed that it seems to affect candidates who've recently logged in:

https://refugeejobsmarket.slack.com/archives/C42S4AJ73/p1718864092378979

[samschlicht]

I'm not able to replicate this in dev: PartnerService.getAutoAssignablePartnerByCountry would be the main culprit, but it appears to be working fine. I'll keep an eye on this, and in the meantime I've taken the following steps:

• Assigned the 6 candidates with BOSCO as managing partner to MAP India, via direct DB edit
• Set BOSCO to inactive in AP > Settings > Partners

[sadatmalik]

Adding some notes following discussion in today’s team meeting:

The problem likely stems from the introduction of the Redis caching layer for service calls to the users table. User lookups by username in the UserRepository are cached for faster subsequent reads, and cached entries are evicted when new user details are saved via the UserRepository.

Current Issue:

We have directly updated the user table in the database, bypassing the service and repository methods. This bypass means the cached entry is not evicted, potentially causing a mismatch between the cache and the database.

Further Testing:

Sam will test the following hypothesis:

1. The candidate logs into the candidate portal.
2. The candidate’s user data is cached in Redis.
3. The user entry is directly modified by an admin in the database, updating the partner info but bypassing Redis cache eviction.
4. The candidate updates their details in the candidate portal.
5. When saved, the old partner info (now stale) has bee read from the Redis cache and reapplied to the DB.

Proposed Solution:

Whenever direct database updates are made to the users table, bypassing the TC service, the Redis cache should be completely cleared to ensure it repopulates with the correct information.

[samschlicht]

I'm not sure why I wasn't able to replicate the error before, but I can now!

After direct DB edit of partner_id, if the user logs in to their candidate profile and/or saves their contact info: partner_id reverts to the previous value.

Our suspicion was correct! Fixed in dev:

• change partner via direct DB edit
• in terminal: docker exec -it docker-compose-redis-1 redis-cli FLUSHALL
• partner-id no longer reverts when user logs in/edits contact info

[samschlicht]

I've edited the users still attached to BOSCO, so now I just need to meet with @sadatmalik re how to flush the prod Redis cache.