In this specific case, a JMS message is supposed to contain an offer code. Offer codes are like price schedules, i.e. items with offer code X are .99$ until 2012, and then they become .50$ owing to the collapse of civilization, or something like that. But apparently offer codes can change. If civilization doesn't collapse, they may decide to keep the .99$ price until 2013.
We don't store prices, we just store offer codes. This is good for us because generally we don't care if the price schedule for a given product changes, since the offer code stays the same. However, one of the kinds of products is a bundle, which contains a number of other products. A bundle's price is based on the price schedules of all the products it contains. So even though we don't have to do anything to a product if its offer code's price schedule changes, we do have to recalculate the price schedules of all the bundles that contain that product and get new offer codes for them.
That's what this JMS message is about. It signals when an offer code has changed and therefore when we get one we have to find all the bundles that contain products with that offer code. Not the products themselves, just the bundles that contain them, and we flag them for reprocessing.
The bug QA filed was that they were sending a test message with a given offer code and seeing no changes in the table that lists what bundles are waiting to be repriced. I spent 2 hours on testing the code end to end to ensure that if I sent a JMS message into the queue that it was picked up and processed by the application. This was actually stupid on my part* because after I was done with that and had verified everything worked fine, I looked at the test database to see what the data they were working with was. There was exactly one product with the offer code in question, and it was included in no bundles at all. The application was making no change to the database because there was nothing matching the criteria of what it was supposed to change.
* This wasn't really stupid on my part. I've had enough situations where there's both a flaw in the program and a flaw in QA's process that by pointing out the latter and closing the bug I just end up having to come back to it the next day.