Custom cache max age of Apigee entities are not bubbling up to rendered entity display modes

[mxr576]

Description

Please bear with me; this is going to be a long one with lots of screenshots...

TL;DR Custom cache max age MUST BE defined on Apigee entities because if they are not, then rendered results via entity display modes (introduced in #402) will not respect Apigee entity-specific caching settings.

The original bug report from a customer was that they approved an API product association on Apigee Edge MGMT UI. However, even after 48 hours, the developer portal still shows that the API product association on the app is pending.

We need a clean Drupal installation with the latest Apigee Edge 3.x and Render cache debug output configured in the development environment. Having kint() (configured)[https://www.drupal.org/docs/theming-drupal/twig-in-drupal/discovering-and-inspecting-variables-in-twig-templates#s-debugging-with-kint] as debugger is a nice to have, it makes easier to search inside dumped debug information from Twig.

Apigee Info

N/A

Steps to Reproduce

Considering that we have a simple authenticated user called "test user" with an app "test app".

When test user first visits the "My apps" page we can see the following render debug information in the inspector:

The pre-bubbling cache max-age is -1 (permanent), but it was overridden as part of rendering to 1 (second). If we think a bit, this already smells because the default cache max age of developer apps is 900s, so pre-bubbling should have been 900 not permanent (spoiler, which is the default max age of entitys).

Where does that 1 come from? Let's add {{ kint(content) }} to apigee-entity.html.twig and search for max-age, tada:

The field formatter of the "Last updated" field overrode the pre-bubbling cache max-age (which was also wrong, but please bear with me...).

If we change the "Time ago" formatter to "Default" for the "Last updated" at /admin/config/apigee-edge/app-settings/developer-apps/display what do we get?

Let's cut it short; this originates from the "Created" fields "Time ago" formatter; changing that to "Default" makes the cache max-age of the entity display to -1. (I spared some storage with one less screenshot, please believe me :) )

So we learned that field formatters have an influence on the cacheability of the rendered entity display modes.

If we roll back our changes to restore the 1s cache max age for the render result, then every change made on Apigee Edge MGMT UI/API becomes immediately visible on the test app, right? NO, because at the entity storage level, the default 900s (15 minutes) cache expiration is still applied, so the system keeps re-rendering the same output for 15 minutes --- which is required for adequately formatted dates with those field formatters.

What happens when "Last modified" and "Created" fields are both using the "Default" formatter, or they were removed from the entity display mode? The max-age of the rendered app display becomes permanent. :bomb: (See the original bug report by the customer, on that project these fields weren't part of the entity display.)

In the TL;DR I wrote...

Custom cache max age MUST BE defined on Apigee entities because if they are not then rendered results via entity display modes

A simple answer for the why: https://github.com/drupal/core/blob/10.1.2/lib/Drupal/Core/Entity/EntityViewBuilder.php#L188

If this method is overridden in every Apigee entity that has a custom cache max age setting, then the cache TTL of the entity data (in cache_apigee_edge_entity) and the rendered entity view (in cache_render) become to be in sync. This eliminates the permanantly cached app display issue when there are no field formatters or anything on the current render context that would override the default cache TTL of entitys (again, -1).

Actual Behavior

The render arrays cache max age is different than the configured cache max age for the given Apigee Entity.

Expected Behavior

The render arrays cache max age matches with the configured cache max age for the given entity.

Screenshots

If applicable, add screenshots to help explain your problem.

Notes

Version Info

1.x||2.x||3.x

[shishir-intelli]

Thank you @mxr576 for the detailed explanation and for your contribution.

I agree that the render arrays cache max age is not synced properly. Thank you for creating PR for this issue, We will review the PR.

[shishir-intelli]

@mxr576

See the original bug report by the customer, on that project these fields weren't part of the entity display.

where is this?

[mxr576]

The original bug report from a customer was that they approved an API product association on Apigee Edge MGMT UI. However, even after 48 hours, the developer portal still shows that the API product association on the app is pending.

I was referring to this line.

[shishir-intelli]

Reopening this issue because tests are failing.

[mxr576]

Hm... but all tests passed when I created the PR... maybe some new ones are failing and the branch was not rebased before merge? :thinking:

[shishir-intelli]

The Github action tests runs directly on the 3x branch without checking the new changes in the PR, we usually check our forked branch for test cases to pass once we create PRs. I could see you have not configured the Github action in your fork so you might have missed the errors.

[mxr576]

The Github action tests run directly on the 3x branch without checking the new changes in the PR, we usually check our forked branch for test cases to pass once we create PRs.

Hmm... that sounds odd to me as the CI on this repo is not the primary quality gate at this moment.

[shishir-intelli]

The Github action tests run directly on the 3x branch without checking the new changes in the PR, we usually check our forked branch for test cases to pass once we create PRs.

Hmm... that sounds odd to me as the CI on this repo is not the primary quality gate at this moment.

Yes, So we check our fork for test cases to pass.

Creating a PR which will fix PHPCS and test fail issue for the PR #917 merged.