How to prevent caching of AccessResults when orIf() is involved?

Okay, so from this nested IF condition, the following triggers the merge $this->getCacheMaxAge() === 0 && $other->isAllowed() . Which should be the case...

// 2. This access result is not cacheable and $other's access result is the
// same. i.e. attempt to return a cacheable access result.

Still trying to figure out the logic behind the current implementation... maybe if both access results say allowed and one would kill caching then optimize for a better cache hit ratio and use the maximum cache max-age value instead of the minimum (like in andIf())?

Even after 🐛 AccessResult::orIf() has meaningless checks Fixed was closed, the reported issue still exists and the merge is decided by the same (refactored) line.

https://git.drupalcode.org/project/drupal/-/commit/1c814ad4277296875b9bd...

This is something that can be evaluated using a truth table (using Allowed for TRUE and Forbidden for FALSE).

| Partial Result | A Allowed | A Forbidden |
| B Allowed      | Allowed   | Allowed     |
| B Forbidden    | Allowed   | Forbidden   |

Based on these results we can see that if B is allowed (TRUE) then the result itself is independent of A. So if B is Allowed then we indeed don't need to look at A or A's cacheability. So with that in mind I would expect that if B is forever cacheable and B is allowed, then the result is also forever cacheable; because the result won't change if A changes.

It's important that in case B is Forbidden (FALSE) we do cache based on A's cacheability because it entirely dictates the possible outcome.

Because of the commutative properties of the "or" operation, I would expect this behaviour also if B (endlessly cacheable) was provided first and A (uncacheable) was provided in the orIf.

----------

The above is how I believe, based on the described logic, how Drupal should work. So this would be contradicting your steps to reproduce (where the result should be "cacheable to infinity"). However, I don't quite understand Drupal's comments so I can't comment on whether the current implementation matches the above outline.

mxr576 → closed merge request !8369

Okay, it took some time to realize that for sure, this works as designed.