Steps to Reprocess the 'FAILED' packets(INTERNAL Doc)

Steps to Reprocess the 'FAILED' packets(INTERNAL Doc)

A packet may fail due to various reasons, such as network disruptions, unavailable dependent services, or service failures. In many such cases, the issue can be resolved by reprocessing the packet—either from the beginning or from the specific stage where the failure occurred.
This document provides detailed guidelines for reprocessing failed packets.


Pre-reprocessing checks

Perform the following necessary prechecks to ensure that all required conditions are met before initiating the packet reprocessing.

  • In the registration table, verify the value of the reg_process_retry_count column to ensure that it has not exceeded the maximum number of allowed reprocessing attempts as configured in the following property.
    In the registration processor default properties – > registration.processor.reprocess.attempt.count

image-20250610-061341.png


1. To reprocess the packet from the beginning

Authentication and Authorization

The MOSIP components need to authenticate themself to retrieve an authentication token and use the same in the header of every API call.

URL

POST https://{{url}}/v1/authmanager/authenticate/clientidsecretkey

Sample Request

{ "id": "string", "metadata": {}, "request": { "appId": "regproc", "clientId": "mosip-regproc-client", "secretKey": "xxxxxxxxx" }, "requesttime": "2018-12-10T06:12:52.994Z", "version": "string" }

Sample Response

{ "id": "string", "version": "string", "responsetime": "2025-06-10T05:20:16.192Z", "metadata": null, "response": { "status": "Success", "message": "Clientid and Token combination had been validated successfully" }, "errors": null }

 

API Endpoints


Provide the RID and the corresponding workflowInstanceId from the registration table in the mosip_regproc database, and reg_type, whether it is NEW, UPDATE, OR LOST as part of the reprocessing request.

URL

POST {{url}}/registrationprocessor/v1/securezone/notification

Sample Request

{ "reg_type":"NEW", "rid":"10082100560002420250519110432", "isValid":true, "internalError":false, "messageBusAddress":null, "retryCount":null, "tags":null, "lastHopTimestamp":null, "source":null, "iteration":1, "workflowInstanceId":"56a335aa-34ca-4c41-98ca-cca1287eced5" }

Sample Response

image-20250610-061946.png

2. To reprocess the packet from a specific stage

The following query will reprocess the failed packets from a specified stage, especially when the packet has failed after the uin generation stage.

Here, the query example is given for the finalization stage.


Ensure that the column values latest_trn_typ_code and reg_stage_name match the stage from which the packet needs to be reprocessed, and update the latest_trn_dtimes column with the Date.
After the RID status is updated, the reprocessor will pick the packet at the configured time interval for reprocessing.

update regprc.registration set status_code ='PROCESSING', latest_trn_type_code = 'FINALIZATION', latest_trn_status_code ='REPROCESS', reg_stage_name ='FinalizationStage', latest_trn_dtimes ='2025-06-09 00:00:30.630802' where reg_id = '10082101920001820250603123412'

Verification

To confirm that reprocessing has occurred, verify the relevant entries in the registration_transaction table. The packets should have been reprocessed starting from the SECUREZONE_NOTIFICATION stage.

image-20250610-062319.png

------end-------