Bug 416652 - When create job with REST or CLI fails all traces of job must be removed
Summary: When create job with REST or CLI fails all traces of job must be removed
Status: RESOLVED FIXED
Alias: None
Product: Hudson
Classification: Technology
Component: Core (show other bugs)
Version: 3.1.0   Edit
Hardware: PC Mac OS X
: P1 blocker (vote)
Target Milestone: ---   Edit
Assignee: Bob Foster CLA
QA Contact: Geoff Waymark CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-05 13:39 EDT by Bob Foster CLA
Modified: 2013-09-16 11:52 EDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bob Foster CLA 2013-09-05 13:39:14 EDT
That goes for copy-job and update-job (create) as well.

A user submitted a config.xml file that was garbage. It had quotes around the entire file and the character sequence '\r\n' between each line (not CR LF, but those 4 characters). Job creation failed with a 500. Nonetheless, the job was created with the bad config.xml and Hudson later threw an NPE trying to load it. This happened during the updating of the dependency graph.

Note that suppressing the NPE does not fix the problem of creating a broken job.

org.jvnet.hudson.reactor.ReactorException: java.lang.NullPointerException
    at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:246)
    at hudson.model.Hudson.executeReactor(Hudson.java:726)
    at hudson.model.Hudson.<init>(Hudson.java:623)
    at org.eclipse.hudson.init.InitialRunnable.run(InitialRunnable.java:51)
    at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.NullPointerException
    at hudson.model.LazyTopLevelItem.hasPermission(LazyTopLevelItem.java:272)
    at hudson.model.Hudson.getItems(Hudson.java:1310)
    at hudson.model.Hudson.getItems(Hudson.java:229)
    at hudson.model.Hudson.getAllItems(Hudson.java:1368)
    at hudson.model.DependencyGraph.<init>(DependencyGraph.java:78)
    at hudson.model.Hudson.rebuildDependencyGraph(Hudson.java:3610)
    at hudson.model.Hudson$12.run(Hudson.java:2422)
    at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146)
    at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259)
    at hudson.model.Hudson$4.runTask(Hudson.java:706)
    at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187)
    at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
    ... 1
Comment 1 Danny Ju CLA 2013-09-05 15:21:29 EDT
The CURL command which be used to reproduced the issue is:

curl -X POST "http://USERNAME:PASSWORD@HOST_AND_HUDSON_PATH/hudson/createItem?name=newjob1" --data-binary "@new-config.xml" -H "Content-Type: text/xml"
Comment 2 Bob Foster CLA 2013-09-05 19:34:54 EDT
There's an extra /hudson in your example. That is part of the hudson path in DCS. I tested with:

curl -X POST "http://bob:bob@localhost:8080/createItem?name=Garbage" --data-binary "@garbage" -H "Content-Type: text/xml"
Comment 3 Bob Foster CLA 2013-09-05 19:39:34 EDT
Fixed by commit 4c75ffcc0e99d350cbab5f50f80a3a23435f9bac

Tested with both REST createItem and CLI create-job. It will be the same for anything that creates a job from XML.
Comment 4 Bob Foster CLA 2013-09-05 19:43:22 EDT
Changed to P1 blocker, as a) this is a regression in 3.1.0 and b) when it happens Hudson is essentially broken as it can no longer list jobs.
Comment 5 Bob Foster CLA 2013-09-13 13:14:21 EDT
The update case in update-jobs CLI still needs to be fixed.
Comment 6 Bob Foster CLA 2013-09-13 13:14:49 EDT
Fixed by commit c80ccc77a413be45597b4d5b4b5714ee1845ddaa
Comment 7 Latha Amujuri CLA 2013-09-16 11:52:17 EDT
Verified fixed in SNAPSHOT build #500