Resident Service Update my data

{
“id”: null,
“version”: “1.0”,
“responsetime”: “2026-01-27T15:01:06.819Z”,
“metadata”: null,
“response”: null,
“errors”: [
{
“errorCode”: “RES-SER-412”,
“message”: “Unable to access API resourceRES-SER-411 → Could not fetch machines from master data; \nnested exception is io.mosip.resident.exception.ResidentMachineServiceException: KER-MSD-342 → No zone assigned to the user”
}
]
}

When updating resident contact details, should the service be calling the Master Data API to fetch machines and zones based on the user ID?
If so, is the resident user ID a valid identifier to use when looking up a zone?
The userId is obtained from the authenticated user:
String userId = ((UserDetails) SecurityContextHolder.getContext().getAuthentication().getPrincipal()).getUsername();
and the user making this request is the Resident Service.

Hi @ZeD Thanks for reaching out.

Yes — when updating resident contact details (for example, Update UIN), the Resident Service does interact with Master Data to fetch or manage machine information, but this behavior depends on the Resident Service version you are using.

:white_check_mark: Java 21 – Resident Services v1.3.0 (Latest)

If you are using the latest Java 21 version (v1.3.0):

:backhand_index_pointing_right: In this flow, the zone association is handled via the machine, not directly via the resident user ID.


:warning: Java 11 – Resident Services v1.2.1.3

If you are using Java 11 (latest available v1.2.1.3):

  • The machine activation logic is missing due to a known issue.

  • Because of this, even though the machine may be created, it is not activated, which can result in errors like:
    KER-MSD-342 → No zone assigned to the user

  • This issue has been fixed in v1.3.0 (Java 21) but is not backported to Java 11.

Code reference (Java 11 path where activation is missing):
https://github.com/mosip/resident-services/blob/d46aa35effbb8dc4a7a0ab9bfc8adc042dfcde7c/resident/resident-service/src/main/java/io/mosip/resident/service/impl/ResidentServiceImpl.java#L833


:magnifying_glass_tilted_left: About userId and zone lookup

  • The userId obtained from:

    String userId =
        ((UserDetails) SecurityContextHolder.getContext()
            .getAuthentication()
            .getPrincipal())
            .getUsername();
    
    

    represents the authenticated resident user, not a Master Data user.

  • Therefore, zone assignment is not expected to be resolved directly using the resident user ID.

  • Zone resolution happens via the machine configuration in Master Data, not via the resident user.


Recommendation:
For environments where Update UIN is required, it is strongly recommended to use Resident Services v1.3.0 (Java 21) to avoid machine activation and zone-assignment issues.


Regards,
Kamesh Shekhar Prasad
Developer – Resident Services

1 Like

Hello @Kamesh Thank you so much for ur reply, I really appreciate this.

About my environment, I’m using Resident Service 1.2.1.2 Java 11.

Issue Description

To explain the issue more clearly, here is the scenario I am facing:

When I request an update to my personal data, specifically contact details such as an email address or phone number, the update process triggers a call from the Resident Service to the following endpoint in the masterdata service :

${mosip.kernel.masterdata.url}/v1/masterdata/machines/search


public ResponseWrapper<PageResponseDto<MachineSearchDto>> searchMachine(
       @RequestBody @Valid RequestWrapper<SearchDtoWithoutLangCode> request) {
    auditUtil.auditRequest(MasterDataConstant.SEARCH_API_IS_CALLED + MachineSearchDto.class.getCanonicalName(),
          MasterDataConstant.AUDIT_SYSTEM,
          MasterDataConstant.SEARCH_API_IS_CALLED + MachineSearchDto.class.getCanonicalName(),"ADM-906");
    ResponseWrapper<PageResponseDto<MachineSearchDto>> responseWrapper = new ResponseWrapper<>();
    responseWrapper.setResponse(machineService.searchMachine(request.getRequest()));
    auditUtil.auditRequest(
          String.format(MasterDataConstant.SUCCESSFUL_SEARCH, MachineSearchDto.class.getCanonicalName()),
          MasterDataConstant.AUDIT_SYSTEM,
          String.format(MasterDataConstant.SUCCESSFUL_SEARCH_DESC, MachineSearchDto.class.getCanonicalName()),"ADM-907");
    return responseWrapper;
}

So as I said, the resident_service that makes this call.

As part of this process, the request enters the following method.

public List<Zone> getSubZones(String langCode) {
    String userId = ((UserDetails) SecurityContextHolder.getContext().getAuthentication().getPrincipal()).getUsername();
    ZoneUser zu=zoneUserRepository.findZoneByUserIdActiveAndNonDeleted(userId);

    if(zu == null) {
       logger.error("User {} not mapped to any zones!!", userId);
       return Collections.emptyList();
    }

    List<Zone> zones = getZones();
    String lang = (langCode==null || langCode.equals("all")) ? languageUtils.getDefaultLanguage() : langCode;
    List<Zone> langSpecificZones = zones == null ? Collections.EMPTY_LIST : zones.stream().filter(i -> lang.equals(i.getLangCode()))
          .collect(Collectors.toList());

    List<Node<Zone>> tree = zoneTree.createTree(langSpecificZones);
    Node<Zone> node = zoneTree.findNode(tree, zu.getZoneCode());
    return zoneTree.getChildHierarchy(node);
}

String userId = ((UserDetails) SecurityContextHolder.getContext().getAuthentication().getPrincipal()).getUsername();

When this line is executed, the userId holds the following value:

service-account-mosip-resident-client

So my question is about this logic:

Is this behavior correct?

If not, what is the expected scenario?
Should it userId contain the authenticated userID instead?

If it should hold the authenticated user, this user only a resident ???

Thank you so much again.

Hi @ZeD

Thanks for the detailed explanation and for sharing the code snippets — that really helps :+1:

Short answer

Yes, this behavior is correct.
In Resident Service v1.2.1.2 (Java 11), the userId being resolved as
service-account-mosip-resident-client is expected behavior.


Explanation

When a resident updates personal details (email / phone), the request flow is:

  1. The Resident UI / Client invokes the Resident Service.

  2. The Resident Service internally calls the Master Data service (for example, /v1/masterdata/machines/search).

  3. This internal service-to-service call is authenticated using the Resident Service’s service account, not the end-user (resident) identity.

Because of this, when the following line executes in Master Data:

String userId = ((UserDetails) SecurityContextHolder
        .getContext()
        .getAuthentication()
        .getPrincipal())
        .getUsername();

the resolved userId is:

service-account-mosip-resident-client

This is by design for Java 11–based Resident Services.


About zones and user mapping

  • The resident user is not expected to be mapped to zones in Master Data.

  • Zone-based access is designed for system / admin / operator users, not residents.

  • In this flow, zone resolution is attempted using the service account, which explains why you may see:

    No zone assigned to the user
    
    

This does not mean the resident is incorrect or missing — it simply reflects that the operation is being executed under the Resident Service identity.


Expected behavior (Java 11 – v1.2.1.2)

  • userIdResident Service service account

  • Resident identity → not propagated to Master Data

  • Zone lookup → not applicable for residents


Important note

This behavior was improved in Java 21 (Resident Services v1.3.0), where:

  • Machine creation and activation flows are handled more cleanly

  • Zone and machine handling issues during Update UIN are resolved

For Java 11, this limitation is known and expected.


Hope this clarifies the behavior. Please let me know if you need help validating your setup or understanding how this differs in v1.3.0.

Regards,
Kamesh Shekhar Prasad
Developer – Resident Services

Hello again @Kamesh

If I understand correctly, each service must be associated with a zone ??? Because you said this is the expected behavior, should we onboard each service to a zone?

You recommended upgrading to Resident Services v1.3.0. Will this version work in an environment that is currently running v1.2.x, or does it require a full environment upgrade (including Java 21 and related dependencies)?

Thank you for being so helpful.

Hello again @Kamesh ,

I’d like to follow up on our previous discussion to clarify a couple of points.

From your explanation, I understand that the current behavior is expected. Does this mean that each service must be associated with a specific zone? If so, should we proceed with onboarding each service to a zone individually?

Additionally, regarding your recommendation to upgrade to Resident Services v1.3.0, would this version be compatible with an environment that is currently running v1.2.x? Or would it require a full environment upgrade, including Java 21 and any related dependency updates?

Thank you again for your guidance and support. I appreciate your help in clarifying this.

Best regards,

Hi @Zed ,

Yes, you are right — if you upgrade to Resident Services v1.3.0 (Java 21), then a full environment upgrade is required to maintain compatibility across modules.

If you want to stay on Java 11, you can use the latest v1.2.1.3 image. However, in that case, you must also deploy the compatible modules listed here:
https://docs.mosip.io/1.2.0/roadmap-and-releases/releases/resident-services-v0.9.1#id-6.-compatible-modules


Regarding your question about zones:

This is not related to services being mapped to zones.

Zone mapping is associated with the user, not the service.

The user account you are using to log in must be mapped to the appropriate zone in Master Data. If the user is not mapped to the respective zone, the operation will fail.

So there is no need to onboard each service to a zone individually. Instead, ensure that the authenticated user is correctly zone-mapped.

Hope this clarifies.

Thanks,
Kamesh Shekhar Prasad
Developer – Resident Services