Description of problem: There is a consumer (ae3b3c63-6023-4874-b013-dd6e4e3f040c) in Candlepin QA which cannot be retrieved, cannot have its identity cert regenerated, and cannot have its entitlement certs regenerated. Version-Release number of selected component (if applicable): 0.9.51.10 How reproducible: Always Steps to Reproduce: 1. Try to retrieve the consumer: curl -vku $CPUSER:$CPPASS -X GET http://qa-candlepin.dist.qa.ext.phx1.redhat.com/candlepin/consumers/ae3b3c63-6023-4874-b013-dd6e4e3f040c 2. Try to regenerate consumer's identity cert: curl -vku $CPUSER:$CPPASS -H 'Content-Type: application/json' -X POST http://qa-candlepin.dist.qa.ext.phx1.redhat.com/candlepin/consumers/ae3b3c63-6023-4874-b013-dd6e4e3f040c 3. Try to regenerate consumer's entitlement certs: curl -vku $CPUSER:$CPPASS -H 'Content-Type: application/json' -X PUT http://qa-candlepin.dist.qa.ext.phx1.redhat.com/candlepin/consumers/ae3b3c63-6023-4874-b013-dd6e4e3f040c/certificates Actual results: In all three steps, a 500 error is returned with this body: {"displayMessage":"Runtime Error Unable to find org.candlepin.model.CertificateSerial with id 639320759809408696 at org.hibernate.ejb.Ejb3Configuration$Ejb3EntityNotFoundDelegate.handleEntityNotFound:157","requestUuid":"65653ab6-030b-4580-b7e3-b0e9a5e732b1"} Expected results: That the user is successfully retrieved, or barring that, that it is possible to repair the user through the API.
The schema for cp_cert_serial is a bit strange: Referenced by: TABLE "cp_certificate" CONSTRAINT "fk16370c54b9410fc" FOREIGN KEY (serial_id) REFERENCES cp_cert_serial(id) TABLE "cp_id_cert" CONSTRAINT "fk456324f64b9410fc" FOREIGN KEY (serial_id) REFERENCES cp_cert_serial(id) TABLE "cp_ent_certificate" CONSTRAINT "fke76508714b9410fc" FOREIGN KEY (serial_id) REFERENCES cp_cert_serial(id) So cp_cert_serial is the parent in the FK relationship while all the cert tables are the children. This arrangement is logically backwards to me, but using one table to unify three tables worth of serial numbers necessitated it. What's strange, therefore, is that a row could be deleted from cp_cert_serial without violating the foreign key constraints.
Based on the attachment in Comment 3: Your database does not have the proper constraints for cp_cert_serial Table "public.cp_cert_serial" Column | Type | Modifiers ------------+-----------------------------+----------- id | bigint | not null created | timestamp without time zone | updated | timestamp without time zone | collected | boolean | not null expiration | timestamp without time zone | Indexes: "cp_cert_serial_pkey" PRIMARY KEY, btree (id) Referenced by: TABLE "cp_certificate" CONSTRAINT "fk16370c54b9410fc" FOREIGN KEY (serial_id) REFERENCES cp_cert_serial(id) TABLE "cp_id_cert" CONSTRAINT "fk456324f64b9410fc" FOREIGN KEY (serial_id) REFERENCES cp_cert_serial(id) TABLE "cp_ent_certificate" CONSTRAINT "fke76508714b9410fc" FOREIGN KEY (serial_id) REFERENCES cp_cert_serial(id) The only way I can see to remedy this situation is to remove the rows from cp_id_cert and null the consumer_idcert_id column for each. Then enforce the constraints. The cert regen should work then. Somehow the tables got messed up and need to be directly repaired.
Thanks for looking at it, William. At this point we may just hold out for a refresh and see what remains. My understanding is that the problem arose around the time frame that this bug was posted because of a build that was released to that ENV, and was then removed. If this isn't an issue in any of the latest candlepin builds, I see no problem with closing this bug.
As per comment 6. Closing as current builds on Stage and Production have the appropriate constraints.