Description of problem: When a Consumer is attached to a stack derived pool its not possible to delete the consumer. The deletion should revoke the stack derived pool, but it doesn't do that. I can observe this behavior with all Candlepin versions, both pre and post batch revoke. Version-Release number of selected component (if applicable): 0.9.X, 2.0 How reproducible: always Steps to Reproduce: 1.Create a consumer with stack derived pool 2. -X DELETE "https://localhost:8443/candlepin/consumers/<UUID> Actual results: Caused by: org.postgresql.util.PSQLException: ERROR: update or delete on table "cp_consumer" violates foreign key constraint "fk_sourcestack_consumer" on table "cp_pool_source_stack" Expected results: Consumer deleted Additional info:
After a little bit more investigation, I found out that this bug cannot be reproduced by the steps I provided. The reason I see this bug is that my data are corrupted. My data contain a STACK_DERIVED pool without a sourceentitlement_id. Because of the sourceentitlement_id missing, the revocation logic cant find this subpool. The sequence of actions that lead to this corrupted database is the actual bug. So far I have no reproducer for this and I am investigating how this can happen. Talking with mstead about this and one theory is that a consumer attached a Pool that is both VDC (uses DERIVED SKU) and has stacking_id. There may be some corner case that leaves the STACK_DERIVED pool without sourcenetitlement_id in the database. FWIW its also possible this is a regression caused by batch revoke.
I will continue more investigation on this. I pulled some more logs from the original reporter.
Steps to Reproduce: 1) Create a stacking, virt_limit subscription with a derived product (that also has a stacking id, different from the sub's one) 2) Refresh pools. This will create a pool and unmapped guest pool from sub (1) 3) Consume the NORMAL pool (2). This will create a STACK_DERIVED pool 4) Delete subscription (1) 5) Refresh Pools Actual results: The STACK_DERIVED pool from (3) will be left on the owner Expected results: The owner doesn't have STACK_DERIVED pool created at (3)