The basket's held lines are read again for every caller in a request, so the visitor own endpoint costs a query it already paid

TransactionLookup::lineBookings() ran an entity query every time it was called and remembered nothing. The entities came back from the entity static cache on later calls, so what repeated was the query finding their ids, once per caller.

Measured on the endpoint serving a visitor their own half of a slot, which reads the basket to build its answer and reads it again to restate the overlay stamp: two lookups where one would do. Now one. Both numbers come from the test added here, run before and after, not from reading the code.

What it does

  • TransactionLookup keeps a transaction's lines for the length of the request, next to the query that fetches them.
  • BookingHooks::forgetPolicyOutcomes() drops them. That hook already fires on yoyaku_booking insert, update and delete to drop resolved policy outcomes, for the same reason: both describe a basket that has moved. Nothing new is registered.

What it is not

A first attempt put the cache on the basket and added an event subscriber to clear it. That was wrong twice over: the subscriber held the cart, so a booking event forced the cart to be built, which needs the private tempstore and therefore a session, and a plain hold died with "There is currently no session available". The cache belongs next to the query, where there is nothing to resolve.

The risk, and the guard

Keeping lines is only safe while they are still true, and a line can change from anywhere: a hold goes through the engine, not through the basket. So the second test reads the basket, holds another line, and reads again, expecting to see it. Removing the invalidation was seen to fail it (actual size 1 matches expected size 2), so it is not a test that would pass either way.

Per request only, bounded by one basket's lines, and any booking write clears it, so a bulk hold is no worse than before rather than better.

Where this came from

Introduced in [#3615965], where restating the stamp on that endpoint was described as costing nothing on the grounds that the basket had just been read. Having read it did not help, because nothing kept the result. Nothing measured that endpoint either, which is why a green pipeline carried it: the map document has a cost test, the available-place reads have one, and the visitor's own half had neither. It has one now.

Merge request reports

Loading