Closed zabeen closed 10 months ago
@mmelchers It will take a few weeks to implement, test and release this.
Could you please investigate whether it is a single org who is responsible for the mass deletes and re-creates, followed by 100s of searches that bring the deleted donors back?
If it is a single org, could you notify them of the reason for the search failures, and ask them to allow 24 hours for donor updates to propagate before running the searches? At least until the fix has been deployed to live.
@zabeen the organisations doing the large updates are in many cases not the organisations that are doing the searches. These donors may appear in searches started by organisations all over the world. We cannot ask those organisations to not start searches for 24 hours, because another organisation is performing a large update.
@mmelchers understandable, but I was just wondering if it was more than a coincidence that there were so many searches failing for this reason so soon after the mass delete/recreate event.
I was hoping S&M db would show a relationship between who is kicking off the searches and who is doing the mass updates.
ExternalDonorCode
, EthnicityCode
and RegistryCode
are being populated for each matching donor result.false
true
To be run with feature flag set to true
Part 1:
Part 2:
Dev work done, but release and testing blocked by #1066
Update: #1066 completed, ticket is ready for testing
@zabeen Hi! From my perspective, testing status: Ok
e93a6917-455d-4489-a437-46bc542ff9f5
- after DEV-ATLAS-MATCHING-DONOR-MANAGEMENT-FUNCTION
pause and upload donor import file with 'delete' donors list
8dba3c96-2a32-4705-9b4d-3bec1daa5ce9
- after DEV-ATLAS-MATCHING-DONOR-MANAGEMENT-FUNCTION
restart
WMDA release completed, see #1066 for release notes.
Dependency of matching on donor store leads to the exception described here #1055
To avoid this issue, three additional fields should be added to the Donors table on matching algorithm db:
ExternalDonorCode
EthnicityCode
RegistryCode
These fields should be set via:
Release Management
useDonorInfoStoredInMatchingAlgorithmDb
false
(default), donor info will be fetched the existing way, via call to the donor store dbtrue
, donor info stored in the new props will be used instead1066 covers setting up FF infrastructure on Atlas
bool
constant as a placeholder for the FFdonor_import
module and use IFeatureManager to grab its value (value should be cached as it will be used on every search).Release steps would thus be:
false
true