Changing allowed_values of list_text fields on Apigee entities potentially times out

[boobaa]

Description

Drupal core has introduced a change (in 10.2.1 if I'm not mistaken) to the admin UI for changing allowed_values for list_text fields (in \Drupal\options\Plugin\Field\FieldType\ListItemBase::storageSettingsForm()): for every allowed_value, the affected entity type's storage is being asked if there is an entity with the given value on the given field, and if so, the Remove button is disabled. (Before this change, there was no such check, so the Remove button was always available, even if there was an entity having the given value on the given field.)

Asking local storage (Drupal DB) is much cheaper than asking Apigee for such values, but that's only one part of the problem. In case of Apigee entities, this check MUST use the Apigee Edge Mgmt API to retrieve anything from that storage. This API does NOT allow conditional retrieval; IOW, when it's asked for those entities that already have a given value in the given field, it returns no entities at all, therefore rendering this core functionality useless. For the team entity type, this can be seen from the logs (with the apigee_edge_debug.module enabled): the GET /v1/organizations/test-boobaa/companies?expand=true HTTP/1.1 request is sent to Apigee Edge, without pagination, without filtering.

Additionally, this very same request is being sent to the Mgmt API for X times during a single page load, where X is the number of already-present allowed_values. One might ask why the response is NOT cached. The answer lies in \Drupal\apigee_edge\Entity\Storage\EdgeEntityStorageBase::doLoadMultiple() which is NOT given any IDs to load (as it should load all entities with the given field having the given value), in which case it MUST NOT respond from its cache as there might be some new entries in the storage in between the API requests (well, at least theoretically).

These things together might lead to PHP timeouts on pages like /admin/config/apigee-edge/team-settings/fields/team.team.field_my_list_text_field if the field already has so many allowed_values (like 100+ for a country field).

Apigee Info

We have seen this happening on both Apigee Edge and OPDK, but theoretically this is also present with Apigee X (given the module uses the same PHP SDK, therefore the same Mgmt API).

Steps to Reproduce

Steps to reproduce the behavior:

1. Add a list_string field to any fieldable Apigee entity type (eg. team) with a handful of allowed_values.
2. Enable apigee_edge_debug.module.
3. Visit the same field's edit page.
4. Visit /admin/reports/dblog to see that Apigee has been called X many times during the last page load.

Actual Behavior

X (the number of same API requests made to Apigee) equals to the number of allowed_values for that field and they're all the same. Also, even when their response is the same (which is like 99.99% of the cases during a single page load), this adds up to the page load time. This eventually leads to a timeout.

Expected Behavior

No timeout should happen, even if the number of allowed_values on that field is relatively high (like 100+ for a country field). As the Mgmt API doesn't allow filtering by field values, Apigee could also be called only once for that page load (covering those 99.99% of the cases when returned entities don't change during a single page load).

Screenshots

Notice that the Remove button next to ANGOLA is NOT greyed out, although there IS an entity with this field value.

Notes

As the entities returned by the Mgmt API most likely don't change during a single page load, it might make sense to cache the result of the first call in memory and avoid calling Apigee that many times.

Version Info

apigee/apigee-client-php                       3.0.5            Client library for connecting to the Apigee Edge API.
drupal/apigee_edge                             3.0.6            Apigee for Drupal.
drupal/core                                    10.4.6           Drupal is an open source content management platform powering millions of websites and applications.
drupal/core-composer-scaffold                  10.4.6           A flexible Composer project scaffold builder.
drupal/core-dev                                10.4.6           require-dev dependencies from drupal/drupal; use in addition to drupal/core-recommended to run tests from drupal/core.
drupal/core-recommended                        10.4.6           Core and its dependencies with known-compatible minor versions. Require this project INSTEAD OF drupal/core.

[kedarkhaire]

Hi @boobaa
Thanks for taking time to define and explain the bug.
Yes I also checked that it does makes API calls on editing list_text or any entity referenced fields.
We will discuss this issue and update here later, meanwhile if you have any solution for it, please feel free to share.
Thanks!