Red Hat Bugzilla – Bug 835288
csprocessor does not replace new topic notation with topic id on push
Last modified: 2013-04-26 01:02:59 EDT
Some info please? eg The content spec that failed, what version you were using, where there any abnormalities when pushing, etc...
All of these details, and the content specification, are marked private (that is why your comment is c#2). You might want to get your bugzilla permissions checked out to make sure they are correct ;). In the meantime I will email the details to you.
Created attachment 594329 [details]
Cheers, thanks Steve and I'll didn't even notice my comment was number so thanks for the heads up.
Fixed will attempt to release a version today. If not I'll get it done first thing tomorrow morning.
Under certain circumstances the input string was returned for the replace function for new topics. The issue was due to a regular expression and returning the wrong item.
New topics weren't being created in the pushed content specification.
Fix the regular expression and the return statement to return the updated output string.
Released as part of 0.24.9
Running cspclient-0.24.10-1.noarch and I tried to add a few new topics this way today and encountered the same behaviour (topics created in skynet, not reflected in the local specification). Has this been tested?
I'm adding topics to the tail end of content spec with ID 9054, I'm wondering if the length/complexity of the spec is still throwing off your regex?
Will test against a live server backup. I was testing against our developer server which has a different REST interface but I didn't see this as an issue.
I've tested it using the revision's that I found for topic 9054 against version 0.24.10 of the CSP and wasn't able to replicate it after multiple attempts.
For a start, I'll add a warning message, if after post processing any new topics are found. That will at least stop duplicate topics being added. As for your issue I'll keep trying to see if I can replicate it.
Closing this as I couldn't replicate it and it has been reported happening again. If it does happen again, please re-open the bug.
Oops "has" should have been "hasn't" in the previous comment.