Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-25925

More polite reporting of NotSerializableException

    XMLWordPrintable

Details

    Description

      If you accidentally store something nonserializable in a local variable, you get a nasty stack trace mentioning org.jboss.marshalling.river.RiverMarshaller.doWriteObject and other things which will make no sense to a user and imply a bug in Workflow rather than in your script.

      RiverWriter should defend better against this. It could replace the bad object with null, after printing a warning in the log. Or it could simply replace it with a pickle that rehydrates to null or throws an exception if you ever resume this flow after a restart. I think replacement with null is preferable since in most cases you did not really need the object to be saved and the flow could have continued without it.

      Attachments

        Issue Links

          is related to

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-27458 Serialization error at end of flow not reported properly in build log, only Jenkins log

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Resolved

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-27421 Unserializable iterator & entry classes from Java Collections

          • Major - Major loss of function.
          • Resolved

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-26137 Mysterious serialization errors

          • Major - Major loss of function.
          • Closed

          Improvement - An improvement or enhancement to an existing feature or task. JENKINS-32213 Must declare classes to implement Serializable

          • Major - Major loss of function.
          • Resolved

          Activity

            Ascending order - Click to sort in descending order
            tg9541 Thomas Goeppel added a comment -

            The real problem is that CPS isn't quite Groovy, and what may be perfectly valid CPS code in one scope (e.g. on the top level, or in node('master') {}) is invalid in other places (e.g. when used in a closure in a map for parallel execution).

            Sometimes being polite is the wrong approach. Avoiding surprises is better.

            tg9541 Thomas Goeppel added a comment - The real problem is that CPS isn't quite Groovy, and what may be perfectly valid CPS code in one scope (e.g. on the top level, or in node('master') {} ) is invalid in other places (e.g. when used in a closure in a map for parallel execution). Sometimes being polite is the wrong approach. Avoiding surprises is better.
            jglick Jesse Glick added a comment -

            Probably what I want to do here is print a warning to the log, then replace with a pickle whose dehydration throws an error. Thus

            • builds which are not resumed will work fine whatever they do
              • but will you will see a warning so you know what to fix as time permits
            • builds which are paused & resumed after the faulty object has been discarded will be fine
            • builds which are paused & resumed while a faulty object is referenced will fail with a relatively clear message
            jglick Jesse Glick added a comment - Probably what I want to do here is print a warning to the log, then replace with a pickle whose dehydration throws an error. Thus builds which are not resumed will work fine whatever they do but will you will see a warning so you know what to fix as time permits builds which are paused & resumed after the faulty object has been discarded will be fine builds which are paused & resumed while a faulty object is referenced will fail with a relatively clear message

            People

              kohsuke Kohsuke Kawaguchi
              jglick Jesse Glick
              Votes:
              7 Vote for this issue
              Watchers:
              11 Start watching this issue

              Dates

                Created:
                Updated: