Uploaded image for project: 'camunda BPM'
  1. camunda BPM
  2. CAM-12326

Open API: the response schema of the "fetch and lock for external tasks" API is missing the nullable flag for some properties

XMLWordPrintable

    • Icon: Bug Report Bug Report
    • Resolution: Fixed
    • Icon: L3 - Default L3 - Default
    • 7.15.0-alpha1, 7.15.0
    • 7.13.0
    • None
    • - NSwag generated client for C# .NET on Windows 10
      - Tried on Camunda RUN 7.13.0-alpha2 and on Camunda embedded engine on version 7.13.0

      Steps to reproduce

      1. Generate an NSwag C# .NET client based on the Open API definition
      2. Perform a "fetch and lock for external tasks" API call

      Expected behavior

      Locked external task objects are returned.

      Observed behavior

      The deserialization of the locked external task objects fails.

      Root cause

      The Open API definition of the LockedExternalTaskDto is missing the nullable flag for the following properties:

      • errorMessage
      • errorDetails
      • processDefinitionVersionTag

        This is the controller panel for Smart Panels app

          1. image-2020-08-25-15-40-33-939.png
            image-2020-08-25-15-40-33-939.png
            65 kB
          2. image-2020-08-25-15-43-39-637.png
            image-2020-08-25-15-43-39-637.png
            74 kB
          3. openapi_adjusted.json
            947 kB

            [CAM-12326] Open API: the response schema of the "fetch and lock for external tasks" API is missing the nullable flag for some properties

            Tassilo Weidner added a comment -

            Hi jiri.halaska,

            Thank you for reaching out to us with your question.

            Your evaluation seems feasible for me. However, I would like to analyze the problem and will come back to you with my results next week at the latest.

            Stay tuned!

            Best,
            Tassilo

            Tassilo Weidner added a comment - Hi jiri.halaska , Thank you for reaching out to us with your question. Your evaluation seems feasible for me. However, I would like to analyze the problem and will come back to you with my results next week at the latest. Stay tuned! Best, Tassilo

            Jiri Halaska added a comment -

            Hello Tassilo.

            Thank you for quick reaction. I will be looking forward to your analysis.

            Best regards,

            Jiri

            Jiri Halaska added a comment - Hello Tassilo. Thank you for quick reaction. I will be looking forward to your analysis. Best regards, Jiri

            Tassilo Weidner added a comment - - edited

            Hi jiri.halaska,

            Thank you for reaching out to us with your question.

            I can confirm that this is unexpected behavior.

            I will forward the bug report for decision making.

            Stay tuned!

            Best,
            Tassilo

            Tassilo Weidner added a comment - - edited Hi jiri.halaska , Thank you for reaching out to us with your question. I can confirm that this is unexpected behavior. I will forward the bug report for decision making. Stay tuned! Best, Tassilo

            Thorben Lindhauer added a comment -

            Hi Jiri,

            Thanks for reporting this. We will probably look into this during the development of 7.15, but cannot guarantee it at this point.

            Cheers,
            Thorben

            Thorben Lindhauer added a comment - Hi Jiri, Thanks for reporting this. We will probably look into this during the development of 7.15, but cannot guarantee it at this point. Cheers, Thorben

            Jiri Halaska added a comment -

            Hello.

            I found this behavior in some other endpoints as well. I would suggest revising the whole API.

            For now as a workaround I simply do a find-replace on the generated code replacing Newtonsoft.Json.Required.DisallowNull with Newtonsoft.Json.Required.Default.

            Certainly not perfect but works.

            Thank you,

            Jiri

            Jiri Halaska added a comment - Hello. I found this behavior in some other endpoints as well. I would suggest revising the whole API. For now as a workaround I simply do a find-replace on the generated code replacing Newtonsoft.Json.Required.DisallowNull with Newtonsoft.Json.Required.Default. Certainly not perfect but works. Thank you, Jiri

            Yana Vasileva added a comment -

            Hello Jiri,

            Are you interested in providing us feedback on the adjustments that we plan to make to fix the issue?
            I am attaching an updated file ( openapi_adjusted.json ) of the 7.15.0-SNAPSHOT version if you want to try it out.

            Best regards,
            Yana

            Yana Vasileva added a comment - Hello Jiri, Are you interested in providing us feedback on the adjustments that we plan to make to fix the issue? I am attaching an updated file ( openapi_adjusted.json ) of the 7.15.0-SNAPSHOT version if you want to try it out. Best regards, Yana

            Jiri Halaska added a comment -

            Hello Yana,

            I had a look at the updates (since 7.13 version) and I see that the issue which I reported was fixed.

            I cannot speak for other possible inconsistencies though because I cannot test if all other endpoints are described correctly in the json.

            Thank you

            Jiri Halaska added a comment - Hello Yana, I had a look at the updates (since 7.13 version) and I see that the issue which I reported was fixed. I cannot speak for other possible inconsistencies though because I cannot test if all other endpoints are described correctly in the json. Thank you

            Yana Vasileva added a comment -

            Hi jiri.halaska,

            Thank you for the feedback.
            We tried to make less strict the the OpenAPI doc for the string properties, but for us is also not possible to test everything and for each language.
            That's why we are always happy to receive feedback from users so we can improve our documentation.
            The issue will be fixed with 7.15.0 release published in April and 7.15.0-alpha1 next month.

            Thank you once again and best regards,
            Yana

            Yana Vasileva added a comment - Hi jiri.halaska , Thank you for the feedback. We tried to make less strict the the OpenAPI doc for the string properties, but for us is also not possible to test everything and for each language. That's why we are always happy to receive feedback from users so we can improve our documentation. The issue will be fixed with 7.15.0 release published in April and 7.15.0-alpha1 next month. Thank you once again and best regards, Yana

            Yana Vasileva added a comment -

            Decision: Enable the nullable field by default for string/date/boolean/array/dto properties as initial problem can occur for each one of them.
            Disable the field only when the fields is strictly required and not used in any request body as a reference.

            Yana Vasileva added a comment - Decision: Enable the nullable field by default for string/date/boolean/array/dto properties as initial problem can occur for each one of them. Disable the field only when the fields is strictly required and not used in any request body as a reference.

              Unassigned Unassigned
              jiri.halaska Jiri Halaska
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: