Description of problem:
It is possible for the cp_pool.quantity_consumed value to be a different value compared to the sum of all the entitlement consumed values for that pool. This remains even after a refresh.
In prod, we encountered this error when a customer couldn't attach to a pool because the limit was reached, even though the customer knew that couldn't be the case. Double-checking showed this to be the case: quantity_consumed = 3, but the actual consumed value was 2.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Can't reproduce it yet, but it is possible to find cases where this has already happened. Query:
FROM (SELECT p.id AS owner_id,
p.quantity AS quantity,
p.quantity_consumed AS stated_consumed,
c.actual_consumed AS actual_consumed
FROM cp_pool p
JOIN (SELECT pool_id,
COALESCE(Sum(e.quantity), 0) actual_consumed
FROM cp_entitlement e
WHERE e.owner_id IN (SELECT id
GROUP BY pool_id) c
ON p.id = c.pool_id
WHERE p.owner_id IN (SELECT id
FROM cp_owner)) calc
WHERE calc.stated_consumed <> calc.actual_consumed;
Some pools state they are consuming a value different than what they are actually consuming.
cp_pool.quantity_consumed equals the sum of all the entitlements consumed amounts for that pool.
Research from the Candlepin team has found that the calculation for this field is lost due to lack of @Transactional annotation.