Created attachment 801959 [details] Error trying to re-register the client to SAM
Created attachment 801960 [details] catalina.out error
Looking for more information on how this issue came about. I'll dig through the logs some more, but I was hoping that you may be able to remember. What org was specified when the system was registered? Was this error produced after clicking on the system in the SAM UI? Was this a shared SAM instance. Looks like there were imports happening at the same time.
(In reply to Michael Stead from comment #4) > Looking for more information on how this issue came about. I'll dig through > the logs some more, but I was hoping that you may be able to remember. > > What org was specified when the system was registered? org name: CoresTest > Was this error produced after clicking on the system in the SAM UI? @omaciel and I were testing socket based scenarios. He was unregistering/registering the client and I was watching the SAM UI and the error suddenly showed up in SAM UI. The registration of the client seem to be successful though > Was this a shared SAM instance. Looks like there were imports happening at the same time. As I said above, omaciel and I were testing this. This sam instance is not shared with anybody else.
Reproduced in dev environment. Based on the log we can see two threads trying to regenerate the same entitlement in close succession. (threads 1 and 4) So what happened, a manifest was imported which updated some part of a subscription from a previous manifest. (most likely the attributes changes, or content was added/removed) Meanwhile a consumer on the same had subscribed between the two events. When the new manifest is imported, the consumer's entitlements are marked dirty so they will be regenerated the next time someone checks those certificates. There are a number of API calls that can trigger the regeneration, it looks like in this case, two of them happened at the same time. One of those requests will (correctly) fail. It's probably more so a matter of how we handle the failure. To reproduce for developers: (dgoodwin@lenovo {master} ~/src/candlepin/buildconf/scripts) $ cat consumer-with-ents.rb #!/usr/bin/env ruby # # Script to create a valid candlepin export.zip which can then be imported # for an owner. Creates everything necessary, starting with a fresh owner, # admin user, candlepin consumer, products, subs, pools, and entitlements. # # None of the above will be cleaned up. require "../../client/ruby/candlepin_api" require 'pp' ADMIN_USERNAME = "admin" ADMIN_PASSWORD = "admin" HOST = "localhost" PORT = 8443 def random_string prefix=nil prefix ||= "rand" return "#{prefix}-#{rand(100000)}" end cp = Candlepin.new(ADMIN_USERNAME, ADMIN_PASSWORD, nil, nil, HOST, PORT) owner = cp.create_owner random_string("consumertest") puts "Created owner: #{owner['key']}" product1 = cp.create_product(random_string(), random_string(), {:attributes => {"multi-entitlement" => "yes"}}) end_date = Date.new(2025, 5, 29) sub1 = cp.create_subscription(owner['key'], product1['id'], 2000, [], '', '12345', nil, nil, end_date) cp.refresh_pools(owner['key']) pool1 = cp.list_pools(:owner => owner['id'], :product => product1['id'])[0] org_admin_username = random_string("orgadmin") org_admin_password = 'password' cp.create_user(org_admin_username, org_admin_password, true) org_admin_cp = Candlepin.new(org_admin_username, org_admin_password) consumer = org_admin_cp.register(random_string('dummyconsumer'), "candlepin", nil, {}, nil, owner['key']) puts "Created consumer: id = #{consumer['id']}, uuid = #{consumer['uuid']}" consumer_cp = Candlepin.new(nil, nil, consumer['idCert']['cert'], consumer['idCert']['key'], HOST, PORT) ent_count = 100 puts "Grabbing #{ent_count} entitlements" (0..ent_count).each do |i| consumer_cp.consume_pool(pool1['id'], {:quantity => 1}) end This creates a consumer with 100 ents, which will take awhile to regenerate. Then we go mark them dirty manually in the db to prevent mucking about with manifests, make sure to use the consumer *ID* printed above, not the UUID. update cp_entitlement set dirty = 't' where consumer_id = '40288198415a8da701415a9589ed01fd'; Now on two separate command lines, get this command ready to go, this time we use *UUID* from output of script: curl -k -u admin:admin -X GET "https://localhost:8443/candlepin/consumers/529a7ee5-bcaf-4349-b08e-4c1ad5a70eb0/certificates/serials" Then go launch the command on one, then on the other. One of the two will fail with: { "displayMessage" : "Runtime Error org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1 at org.hibernate.jdbc.Expectations$BasicExpectation.checkBatched:85" }%
I do not believe this issue is a blocker. The situation is very strange, it's not an easy bug to hit. You need to get dirty entitlements, which means a manifest import, then consumption in SAM, then a change to the product data on RH side, and a re-import. The error happening is technically what should happen, if two transactions try to do the same thing, one of them has to fail to prevent bad data from being committed, which is what is happening here. I do not believe this is a regression either, this problem would be possible going a long ways back. No damage is done, and a re-try of the request is perfectly safe and will work. We will work on getting better error message out of this or preventing it, but not a blocker IMO.
Proposing SAM 1.4 as per Comment 7 above
The release of Satellite 5.8 we are deprecating the support of Subscription Asset Manager. The release notes for 5.8 can be found at https://access.redhat.com/documentation/en-us/red_hat_satellite/5.8/pdf/release_notes/Red_Hat_Satellite-5.8-Release_Notes-en-US.pdf. I am therefore closing out this bug as WONTFIX. If you believe this to be an error, please feel free tor each out to either Rich Jerrido or Bryan Kearney. Thank you!