CAPL - Bug default text according to the team DoR (Definition of Ready)

01 - PERSON OF CONTACT (PERSON THAT CAN ANSWER QUESTIONS ABOUT THE PROBLEM):

@Cindy de Araujo Soares Moore
02 - PROBLEM (WHAT'S THE ISSUE?):

We faced errors to fan-out records in SQL Processing due to a deleted tenant. It wasn’t removed from the unified allowed list on the tenant deletion operation.

See the Slack thread: https://totvscarol.slack.com/archives/C03LA7B048G/p1699540530074069

Task deleting the tenant on Oct 18th was restarted multiple times: https://totvstechfin.carol.ai/carol-org/tasks/activity/3fef6a40187c4cd980482851a8906514?p=1&ps=25&sort=dateUpdated&order=DESC&filters=%5B%5D

Note that we call TenantAppServiceImpl.removeAllowedEnvironmentFromAllApps before the delete task running. So, the multiple restart is not the issue here.

The suspicion is that the findAll search results didn’t find all apps for the deleted tenant 07a94ed699f7407b94a9b2b14d3a624d . The UAD tenant id was f4e4697e021d4f68b849fa4971607b80.

@Override
  public void removeAllowedEnvironmentFromAllApps(UserAccessDetails tenantUad, String tenantMdmId)
      throws RecordNotFoundException {
    final SearchResults<TenantApp> tenantApps =
        findAll(tenantUad, EntitySpaceType.PRODUCTION, 0, -1, null, null);

    if (tenantApps != null && tenantApps.getTotalHits() > 0) {
      for (TenantApp tenantApp : tenantApps.getHits()) {

        removeAllowedEnvironmentFromApp(tenantUad, tenantMdmId, tenantApp);
      }
    }
  }

https://github.com/totvslabs/mdm/blob/ecfbc8e7585364f42a2e867c25f3870e66a4b187/mdm-services/src/main/java/com/totvslabs/mdm/services/impl/TenantAppServiceImpl.java#L2811-L2822

03 - STEPS TO REPRODUCE (STEP (1...N), VIDEO, SCREENSHOTS, LOGS FOLDER, HEARTBEAT, ETC. – IF IS NOT POSSIBLE TO REPRODUCE EXPLAIN THE REASON):
04 - LINKS (ADD A LINK TO THE BUG OR TO THE TENANT):
05 - EXPECTED BEHAVIOR (LIST THE EXPECTED BEHAVIORS TO CONSIDER THIS BUG AS DONE):

Flows that trigger the removal from the allowed list:

1. Endpoint to remove the tenant from the list → OK
2. Removal of Carol App from Customer → Since the tenant customer UAD that is removing the App does not have permission to change the Unified Tenant document, we need to create a new UAD based on the Unified Tenant to allow this update on the Unified Tenant. → OK
3. Delete Customer Tenant → OK
4. Unsubscribe Carol App → OK

AC.:

• There is a suspicion that for some flows the findAll is trusting on the UAD to find the unified tenant to remove the tenant if present in any of those unifieds with allowed list. However, the request to delete a tenant it is done by an org user. On this case, the flow must happen normally. So we should double check the suspcion brought by Cindy. In other words, is findAll must work to bring all tenantApps, even if the flow is from different uad level.

• Assure that when the user asks to remove a tenant from the allowed list (any flow above), this should happen even if there are errors not related to the tenant removal from the list.
• In order for the flow above (prioritize the removal of tenant from the allowed list) we should have the intermediate steps inside a try/catch operation and if the action fails, we must log on the task (for example if it is a tenant deletion and we failed for example to remove a staging schema, we must log that on the task) and this must not fail the whole process to happen.