Pool_info edge case

[rdlrt]

Describe the bug

If a SPO updates his pool's metadata and then sends future updates that reverts metadata to a previous ID, the meta_id (or pmr_id reference) is not incremented, which means the ORDER BY statement for meta_id would cause trouble for such updates. This primarily impacts pool_info endpoint.

A simple solution would be removing meta_id from ordering, but that reaches back to previous issue (meta_id is populated with a new entry in pool_update table, but the entry in pool_offline_data for that ID is not instant - which could leave a null against a pool ID.

a. The simplest alternate that makes sense would be to use COALESCE to return latest pmr_id against a specified pool (as absence of an update in pool_offline_data table would mean previous data is visible. The question for this path really is whether showing a null for a new update to pool preferable over perhaps a previous entry (pro being null could really show specific state , con being the timing will depend on cache status and not be consistent between instances). b. The alternative could be re-jig the pool_information_cache table to only provide a current view (not worry about history), but that would require update to pool_updates table (perhaps more) to use live data instead - impact needs to be evaluated thoroughly.

In either options, need to also keep in mind that it isnt a very common case, but good to be tackled - should not sacrifice UX.

(Thanks to @hodlonaut for reporting the issue)

[rdlrt]

Discussed on call (16/06/2022) - start with option a, and revisit b later

[rdlrt]

Fixed by cardano-community/guild-operators#1435