HomePhabricator

Fix topic history's revision cache expansion

Description

Fix topic history's revision cache expansion

Cache indices try to store as little data as possible. For a list of
things (like history), it tries to only store an array of IDs in one
cache key, then store all data per entry in separate cache keys. This
should prevent huge cache entries & lots of duplicated data.

That also means that, when you do want to load that data, you just
get the IDs of the entries and have to expand those (load the real
data associated with those IDs)

As you'll see in container.php, the topic history index
(storage.topic_history.indexes.topic_lookup) defines shallow compactor
storage.topic_history.indexes.primary, which means it'll compact/expand
based on the primary key defined there: rev_id.
To expand those entries, it'll query that same index, for rev_id.

That index's retrieval method (findMulti) assumed it would only ever
be called with queries in the form of 'topic_root_id' = ... (which is
how we request data for a particular topic) - it didn't consider that
it would also be called to expand those revisions.

There already was a method findDescendants that queried posts &
summary after it had determined the tree of things inside a topic. I'm
now also accepting more than 'topic_root_id' input & relaying it to
that method. Does the trick!

Meanwhile, I also noticed that the safeguard to not let invalid data
(e.g. missing content from ExternalStore) be cached was incorrect: it
would still cache data if in that same index, other entries are valid.
Instead: it shouldn't cache if anything in there is invalid.

Bug: T103053
Change-Id: Ib92fc4549e8187aef38fbe6f5c87521d336c278b