Hi @malay.pandey,
Thanks for sharing the partner and version details. After looking into this, the behaviour is expected for the Credential Feeder as it stands — and it’s not something the partner configuration can fix.
The <registration-id>-PDF request ID isn’t produced by the partner; it comes from the API path the request takes. When Resident Service requests a digital card, it calls the credential request generator’s v2 endpoint (POST /v2/requestgenerator/{rid}), passing rid = <registration-id>-PDF, which is stored verbatim. The Credential Feeder, however, calls the v1 path with no request ID, so the generator falls back to UUID.randomUUID() (Utilities.generateId()). This happens regardless of whether you point the feeder at mpartner-default-digitalcard — so the UUID you’re seeing in credential_transaction is by design in this job.
Since the Credential Feeder job is not carried forward in the latest release, here is a self-contained code fix you can apply to your build of id-repository-credentials-feeder (no changes needed in id-repository-core). It makes the feeder pass requestId = <registration-id>-PDF for the digital-card partner, which routes that credential through the v2/RID path and stores the deterministic request ID Resident Service expects.
CredentialsFeedingWriter.java
Add a property for the digital-card partner:
// the partner whose credential Resident Service downloads using <registrationId>-PDF
@Value("${mosip.credential.feeder.digital-card-partner-id:mpartner-default-digitalcard}")
private String digitalCardPartnerId;
Keep the Uin entity so regId is available:
@Override
public void write(List<? extends Uin> requestIdEntities) throws Exception {
requestIdEntities.forEach(this::issueCredential);
}
private void issueCredential(Uin entity) {
String uin = decryptUin(entity);
issueUinCredential(uin, entity.getRegId());
issueVidCredential(uin);
publishAuthLock(uin);
}
Issue per-partner, using the deterministic request ID only for the digital-card partner:
private void issueUinCredential(String uin, String regId) {
String digitalCardRequestId = regId + "-PDF";
for (String partnerId : onlineVerificationPartnerIds) {
// Resident Service downloads only the digital-card partner credential, looking it
// up by requestId = <registrationId>-PDF. Passing that requestId routes this partner
// through the v2 (RID) credential path, which stores it verbatim instead of a UUID.
// Other partners keep the existing behaviour (null requestId -> v1 -> UUID).
String requestId = digitalCardPartnerId.equals(partnerId) ? digitalCardRequestId : null;
credentialServiceManager.sendUinEventsToCredService(uin, null, false, null, null,
Arrays.asList(partnerId), uinHashSaltRepo::retrieveSaltById,
credentialStatusManager::credentialRequestResponseConsumer, requestId);
}
}
No new imports are required (Arrays is already imported), and this replaces the existing single-argument issueUinCredential(String).
A few things to keep in mind:
- This assumes
regId (the registration id on the UIN record) is the identifier Resident Service uses to build <rid>-PDF. If your setup uses a different value, adjust accordingly.
- Ensure the feeder’s configured credential type/template and the digital-card partner subscription match what the Digital Card service expects — this change makes the record discoverable by request ID, but the credential itself must still be the digital-card type to render on download.
- The fix only applies to records issued after the patch. For identities already issued with UUID request IDs, you’ll need to re-run the feeder for those records (or update the existing
request_id values to <regId>-PDF) so they become downloadable.
Please do also confirm you’re on Resident Service v0.9.1 with its compatible module versions, as the download flow depends on it.
Hope this helps — let us know how it goes.
Regards, Kamesh on behalf of Team MOSIP