Bug 816004 - Topic ID-title mapping corruption in post-processed specs by server
Topic ID-title mapping corruption in post-processed specs by server
Status: CLOSED CANTFIX
Product: PressGang CCMS
Classification: Community
Component: CSProcessor (Show other bugs)
1.x
Unspecified Unspecified
urgent Severity high
: ---
: ---
Assigned To: Lee Newson
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-24 23:02 EDT by Joshua Wulf
Modified: 2014-10-19 19:00 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-04-26 00:58:56 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Post-processed spec with duplicated topic IDs (11.19 KB, application/octet-stream)
2012-07-17 21:29 EDT, Joshua Wulf
no flags Details
Pre-processed spec that I pushed (11.13 KB, application/octet-stream)
2012-07-17 21:30 EDT, Joshua Wulf
no flags Details

  None (edit)
Description Joshua Wulf 2012-04-24 23:02:15 EDT
I'm adding new entries to my spec, then pushing it to the server. 

Twice now I've gotten back a list of invalid topic title / ID errors.

I haven't modified the existing topics in the spec or in the repository, so the only thing I can think of is that the server is writing the wrong topic IDs into my spec when it processes it and hands it back.

Permissive mode pushing is not useful as a workaround for this issue, as this  aligns the topic title to the topic ID, but the wrong topic ID is being put next to the valid topic title that I specified.

Here's an example. Spec ID is 7069. After pushing the spec, then adding a new chapter and pushing again, I get this error:

ERROR: Line 70: Invalid Topic! Existing topic title doesn't match.
       -> Specified: Last Value Queues [8229]
       -> Topic 8229: Override the Default Group Name
ERROR: Line 80: Invalid Topic! Existing topic title doesn't match.
       -> Specified: Rejected and Orphaned Messages [8035]
       -> Topic 8035: Queue Deletion Checks
ERROR: Line 84: Invalid Topic! Existing topic title doesn't match.
       -> Specified: Queue Threshold Alerts [8180]
       -> Topic 8180: Queue Flow Control Properties
ERROR: Line 98: Invalid Topic! Existing topic title doesn't match.
       -> Specified: Specify Queue Flow Thresholds with qpid-config [6974]
       -> Topic 6974: Durable Queues
ERROR: Line 65: Invalid Topic! Existing topic title doesn't match.
       -> Specified: Message Queue [8227]
       -> Topic 8227: Message Group Example Use Cases
ERROR: The Content Specification is not valid.


cspclient-0.23.2-1.noarch
OS: Fedora release 15 (Lovelock)

JAVA: java version "1.7.0_01"
Java(TM) SE Runtime Environment (build 1.7.0_01-b08)
Java HotSpot(TM) 64-Bit Server VM (build 21.1-b02, mixed mode)
Comment 1 Joshua Wulf 2012-04-24 23:11:25 EDT
Yeah, it's definitely happening on the server.

It is writing the post-processed spec with the wrong topic ID for some topics. There is a pattern to it. 

It writes the same topic ID for two topics (one correctly, one incorrectly). The incorrect one is written first, then the second correct one appears around 7-10 topics later.

Take a look at this, from Spec 7069:

    Last Value Queues [8229]
    Declaring a Last Value Queue [8116]
  Section: Message Groups
    Message Groups [8226]
    Message Group Example Use Cases [8227]
    Message Group Consumer Requirements [8228]
    Configure a Queue for Message Groups using qpid-config [8231]
    Default Group [8230]
    Override the Default Group Name [8229]

Notice the duplicated topic ID 8229. The second instance is correct, the first one is wrong and produces the error.

The next topic in the spec is written as 8035, but it's the wrong topic ID. Notice that it appears later with the correct title.

 Override the Default Group Name [8229]
  Section: Alternate Exchanges  
    Rejected and Orphaned Messages [8035]   
    Alternate Exchanges [8056]
  Section: Queue Sizing
    Controlling Queue Size [8170] [R:T4]
    Queue Threshold Alerts [8180]
    Queue Threshold Alert Configuration [8156]
  Section: Deleting Queues
    Automatically Deleted Queues [8040]
    Queue Deletion Checks [8035]

The next error is interleaved. Notice the topic 8180 between the two instances of 8035 above.

It appears again shortly after the second (correct) 8035 instance:

    Queue Deletion Checks [8035]
  Section: Producer Flow Control [T4]
    Flow Control [8175]  
    Queue Flow State [8182]
    Queue Flow Control Properties [8180]

Again, the second instance is correct - the first instance of the Topic ID has been incorrectly written.
Comment 2 Lee Newson 2012-04-25 03:37:13 EDT
For the printing the line the error occurred on perhaps the debug information could be fine tuned so level 1 would just display the lines (before or after the error). Then actually make more debug output for different levels.
Comment 3 Lee Newson 2012-04-25 03:38:03 EDT
Ignore the previous comment it was meant for Bug #815588
Comment 4 Lee Newson 2012-04-25 19:43:29 EDT
This could be a difficult bug to diagnose the problem of. I have seen it a long time ago but only once and it's never happened again. I suspect it is an issue with a regex expression in the post content spec generation since the topics appear to be created fine but just the wrong ids have been injected.
Comment 5 Lee Newson 2012-04-25 20:43:47 EDT
I need more information as I've gone through every revision stored on the server and can't see any errors. What I need is:

- What new items were you adding? Was it the new topic that got corrupted, was it another new topic or an existing one that got corrupt.
- The revision that the issue occurred at.

What would be handy to have:
- The pre processed spec that you used to push to skynet. (Though if you've got the revision it should be stored on the server)

In future if your going to post a ID and continue to edit the file (which I suspect is why I couldn't find the revision) then can u post the revision number as well.
Comment 6 Lee Newson 2012-04-25 21:21:28 EDT
Another item that would be handy to have is if you added any new tags.

Another possible cause is that the wrong CSP Property value is being set and as such the wrong id is being set for those topics (this only happens for new, cloned or updated existing topics).
Comment 7 Lee Newson 2012-05-19 19:36:05 EDT
Since there's been no response to anything I asked for, I'm closing this bug. If it happens again feel free to open another bug with adequate details.
Comment 8 Joshua Wulf 2012-07-17 21:29:44 EDT
Created attachment 598772 [details]
Post-processed spec with duplicated topic IDs
Comment 9 Joshua Wulf 2012-07-17 21:30:14 EDT
Created attachment 598773 [details]
Pre-processed spec that I pushed
Comment 10 Joshua Wulf 2012-07-17 21:31:21 EDT
Got this behavior again. Attached post-processed spec and pre-processed spec from the push.

It was this push:

INFO: Revisions for Content Specification ID: 8025
-> ID: 161816 on Mon, Jul 16, 2012 at 01:02:20 AM
-> ID: 161812 on Mon, Jul 16, 2012 at 01:00:44 AM
Comment 11 Lee Newson 2012-07-17 21:50:36 EDT
The post content spec contains local changes Revision 161816 though contains the proper post processed content spec.
Comment 12 Joshua Wulf 2012-07-17 21:59:11 EDT
For anyone else who gets this, here's the workaround to fix it:

Do:

csprocessor revisions <specID>

You'll get a list of revisions:

INFO: Revisions for Content Specification ID: 8025
-> ID: 161816 on Mon, Jul 16, 2012 at 01:02:20 AM
-> ID: 161812 on Mon, Jul 16, 2012 at 01:00:44 AM

The top one is the content spec you have now (the post-processed one after your last push) less the local changes you are trying to push now. 

The second one is the pre-processed one from the last push. What's happened is that valid topic IDs from the second one were incorrectly rewritten by the CSP in the top one.

So, get the last good spec: 

csprocessor pull --pre -r 161812

^ Pull the pre-processed spec from your last push

Then, install meld (visual diff tool) or similar (you could use diff on the command line, but it's not so visual and easy).

Then open your local post-processed spec and your recently-pulled pre-processed spec in meld. Your local changes (the ones you just tried to push) will be highlighted, but meld is pretty smart and will match the other lines (as long as your local changes aren't a big restructure).

Look for the mismatched lines, and in a text editor modify the incorrect topic IDs in your local spec to the correct values from the pre-processed revision that you pulled down.
Comment 13 Joshua Wulf 2012-07-24 09:22:27 EDT
I just got this again.

Content spec 8025.

pre-processed: 166669
post-processed: 166673

One thing I notice here is that fixed topic IDs have changed between pre- and post-. There is no way to tell if I pushed with -p, but under normal circumstances that shouldn't happen.

The timestamp on the topic in Skynet seems wrong, because I was doing this around 7pm, not 4.23pm. 

This one is particularly worrying to me because I found it only after I built and noticed something wrong. At the moment I'm staging things to put bugs on ON_QA for a release. I can't be checking to make sure that the right topics are in there manually as well... help!
Comment 14 Joshua Wulf 2012-07-24 09:29:06 EDT
Something else that would help is to keep a backup of the last content spec that was pushed, perhaps in a hidden directory. 

You could do the n-latest pattern: Keep the last five specs that were pushed in a .cache directory or similar. 

Then doing comparisons and troubleshooting would be a lot easier.

My manual workaround atm is to:

1. Copy the contentspec before pushing it
2. Push the spec
3. Open the returned post-contentspec and the copied pre-contentspec in a visual diff tool
4. Make sure that nothing changed that shouldn't have.
Comment 15 Lee Newson 2013-04-26 00:58:56 EDT
Closing this since it hasn't been reported again and how the spec is generated has changed since this bug. If it does happen again feel free to re-open the bug.

Note You need to log in before you can comment on or make changes to this bug.