Local error handling command lost on export / import

[andysteady]

Problem happens on 1.5.1 GA and on 1.5.1 snapshot 209

Create a job with a local error handler
Export the job and import it somewhere else
The content of the local error handler is lost.
Following job exhibits the behaviour:

<?xml version="1.0" encoding="UTF-8"?>

<joblist>
  <job>
    <id>588ddf0f-4ba4-4320-b8bc-7f71e6923354</id>
    <loglevel>INFO</loglevel>
    <sequence keepgoing="false" strategy="node-first">
      <command>
        <exec>echo xx</exec>
        <errorhandler keepgoingOnSuccess="true">
          <node-step-plugin type="localexec">
            <configuration>
              <entry key="command" value="echo yy"/>
            </configuration>
          </node-step-plugin>
        </errorhandler>
      </command>
    </sequence>
    <description/>
    <name>x</name>
    <context>
      <project>PROJNAME</project>
    </context>
    <uuid>588ddf0f-4ba4-4320-b8bc-7f71e6923354</uuid>
    <group>x</group>
  </job>
</joblist>

[gschueler]

looks like a bug in the xml deserialization

[gschueler]

doh: turns out it would help if the tests tested the correct formatting! They were testing this format:

<key>value</key>

But the xml output test were testing the correct format <entry key=".." value=""/> ...

situation: all tests pass, but it's broken 😧

[andysteady]

Would you like me to test this? If so can I have a snapshot number/link please?

[gschueler]

@andysteady sure, if you don't mind testing the latest build from here that would be helpful: http://build.rundeck.org/job/rundeck-development/

If it looks good, we can close the issue. thanks!

[andysteady]

It worked, thanks.
However in deleting a job in order to reload it and test this, I got the following error:

Referential integrity constraint violation: FKAFFFA9275C4E2579: PUBLIC.RDOPTION FOREIGN KEY(SCHEDULED_EXECUTION_ID) REFERENCES PUBLIC.SCHEDULED_EXECUTION(ID); SQL statement: delete from scheduled_execution where id=? and version=? [23003-112]

[gschueler]

thanks, I will log that as a separate issue and see if I can reproduce it

[andysteady]

OK - I have seen it before, I think its something to do with the relationship between jobs. I did try briefly to delete them in reverse dependency order, and bulk delete them all together, but didn't have any luck with that. Cheers, Andy