Releases · mosip/registration

Registration Processor - 1.1.5.4

Added fix - if packet not present in landing zone but present in object store the uploader stage will process the request.
In some of the stages in the registration processor, we were using class-level variables due to which packets marked as “supervisor rejected”, were getting processed. Hence, we have removed the use of class-level variables in the registration processor.
The maximum number of landing zones have been increased from three to ten.
In the registration processor, now we are creating the rest template only once and reusing it for every request to avoid performance issues.
We have observed that in the ABIS Handler stage we are getting multiple requests for the same RID from Kafka. Hence, we have added a fix to ignore duplicate requests coming for the same RID in the ABIS handler stage.
In the case of an insert request, if ABIS sends an error stating that the reference ID is already existing in its gallery, then we are considering it to be a successful response.
In demo deduplication, now we have added an additional check to filter out potential duplicates without biometric reference IDs when we go for bio-match in ABIS. In scenarios where a resident is updating only demographic data there is no record for ABIS, hence, if demo duplicates for such records then, we wouldn’t be able to perform bio-match in ABIS.

Registration Processor - 1.1.5.4

In some of the stages in the registration processor, we were using class-level variables due to which packets marked as “supervisor rejected”, were getting processed. Hence, we have removed the use of class-level variables in the registration processor.
The maximum number of landing zones have been increased from three to ten.
In the registration processor, now we are creating the rest template only once and reusing it for every request to avoid performance issues.
We have observed that in the ABIS Handler stage we are getting multiple requests for the same RID from Kafka. Hence, we have added a fix to ignore duplicate requests coming for the same RID in the ABIS handler stage.
In the case of an insert request, if ABIS sends an error stating that the reference ID is already existing in its gallery, then we are considering it to be a successful response.
In demo deduplication, now we have added an additional check to filter out potential duplicates without biometric reference IDs when we go for bio-match in ABIS. In scenarios where a resident is updating only demographic data there is no record for ABIS, hence, if demo duplicates for such records then, we wouldn’t be able to perform bio-match in ABIS.

Provide feedback