Reducing calls to Ref Data within the start up of Resume

[tvr-hmcts]

HDPI-5414

Note - this is first run at this ticket. As it has been highlighted further work is needed in other areas also from a performance perspective.

Highlighted in performance testing the start of the ResumePossessionClaim is not meeting SLAs. Identified the double call to Ref Data and have changed the approach there.

I profiled this within an integration test and the results of the change are presented in the Jira.

Ran further hibernate based statistics and only one db call is made for the draft data. We can consider additional work there if needed in the future as splitting this using projections.

Further large or more complex refactoring can/will be considered later also such as caching and parallel calls

[github-actions]

CCD diff summary

👉 Full report: https://github.com/hmcts/pcs-api/actions/runs/29080717697?check_suite_focus=true

No change

[hmcts-jenkins-j-to-z]

Plan Result (aat)

⚠️ Resource Deletion will happen

This plan contains resource delete operation. Please check the plan result very carefully!

Plan: 0 to add, 0 to change, 1 to destroy.

• Delete
  • module.postgresql.azurerm_postgresql_flexible_server_configuration.pgsql_server_config["pg_qs.query_capture_mode"]

Change Result (Click me)

  # module.postgresql.azurerm_postgresql_flexible_server_configuration.pgsql_server_config["pg_qs.query_capture_mode"] will be destroyed
  # (because key ["pg_qs.query_capture_mode"] is not in for_each map)
  - resource "azurerm_postgresql_flexible_server_configuration" "pgsql_server_config" {
      - id        = "/subscriptions/1c4f0704-a29e-403d-b719-b90c34ef14c9/resourceGroups/pcs-data-aat/providers/Microsoft.DBforPostgreSQL/flexibleServers/pcs-aat/configurations/pg_qs.query_capture_mode" -> null
      - name      = "pg_qs.query_capture_mode" -> null
      - server_id = "/subscriptions/1c4f0704-a29e-403d-b719-b90c34ef14c9/resourceGroups/pcs-data-aat/providers/Microsoft.DBforPostgreSQL/flexibleServers/pcs-aat" -> null
      - value     = "top" -> null
    }

Plan: 0 to add, 0 to change, 1 to destroy.

[sadmanrahh]

Why was this changed from private to package-private? The tests call the registered CCD handler, not this method directly.

[tvr-hmcts]

Ah I placed an integration test against it at that point. I can switch it back as Im not pushing the integration test as I only used it within the profiling.

[sadmanrahh]

Sure, if you could switch back, would be great!

[sadmanrahh]

Can we extract using AddressUK orgAddress = nameAndAddress != null ? nameAndAddress.address() : null; to avoid the second null check and make the flow clearer?

[tvr-hmcts]

Based on the pattern in the OrganisationDetailsService it is possible for it to fail and then continue - returning null on exception. Ive not changed that pattern, though perhaps that needs revisiting, so it is possible for the response (NameAndAddress) to be null.

[sadmanrahh]

Minor- can we remove extra lines?

[sadmanrahh]

Sure, if you could switch back, would be great!

[guygrewal77]

There's some missing code coverage in a method implemented outside of this PR - getOrganisationAddressForCurrentUser()

[tvr-hmcts]

Though the rationale for this ticket is not really in this area per say but in how we use it. I will take bit more of a look though now as a stepping stone. I think this class and the OrganisationDetailsService may need a revisit in general and there is another ticket that may impact it also - though not in flight yet - https://tools.hmcts.net/jira/browse/HDPI-6650