[AERIE-1691] Return default arguments alongside effective argument failures

[pcrosemurgy]

• Tickets addressed: AERIE-1691
• Review: By commit
• Merge strategy: Merge (no squash)

Description

Adds default arguments alongside the getModelEffectiveArguments /getActivityEffectiveArguments failure response. This will allow the UI to implement default values within forms with the getModelEffectiveArguments /getActivityEffectiveArguments workflow.
See AERIE-1691 for more context.

Verification

Expand

Success Responses

With examples/banananation's all optional arguments:

query TestGetModelEffectiveArguments {
  getModelEffectiveArguments(missionModelId: 1, modelArguments: {}) {
    success
    errors
    arguments
  }
}

→

{
  "data": {
    "getModelEffectiveArguments": {
      "success": true,
      "arguments": {
        "initialDataPath": "/etc/os-release",
        "initialPlantCount": 200,
        "initialProducer": "Chiquita"
      }
    }
  }
}

Failure Responses

With BakeBananaBread, where only the temperature parameter has a default value:

query TestGetActivityEffectiveArguments {
  getActivityEffectiveArguments(missionModelId: 1, activityTypeName: "BakeBananaBread", activityArguments: {}) {
    success
    errors
    arguments
  }
}

→

{
  "data": {
    "getActivityEffectiveArguments": {
      "success": false,
      "errors": {
        "tbSugar": {
          "schema": {
            "type": "int"
          },
          "message": "Required argument for activity \"BakeBananaBread\" not provided: \"tbSugar\" of type ValueSchema.INT"
        },
        "glutenFree": {
          "schema": {
            "type": "boolean"
          },
          "message": "Required argument for activity \"BakeBananaBread\" not provided: \"glutenFree\" of type ValueSchema.BOOLEAN"
        }
      },
      "arguments": {
        "temperature": 350
      }
    }
  }
}

With examples/config-without-defaults's all required arguments:

query TestGetModelEffectiveArguments {
  getModelEffectiveArguments(missionModelId: 1, modelArguments: {}) {
    success
    errors
    arguments
  }
}

→

{
  "data": {
    "getModelEffectiveArguments": {
      "success": false,
      "errors": {
        "a": {
          "schema": {
            "type": "int"
          },
          "message": "Required argument for configuration \"Configuration\" not provided: \"a\" of type ValueSchema.INT"
        },
        "b": {
          "schema": {
            "type": "real"
          },
          "message": "Required argument for configuration \"Configuration\" not provided: \"b\" of type ValueSchema.REAL"
        },
        "c": {
          "schema": {
            "type": "string"
          },
          "message": "Required argument for configuration \"Configuration\" not provided: \"c\" of type ValueSchema.STRING"
        }
      },
      "arguments": {}
    }
  }
}

Documentation

Updated Aerie GQL API documentation: https://github.com/NASA-AMMOS/aerie/wiki/Aerie-GraphQL-API-Software-Interface-Specification#query-for-activity-effective-arguments

Future work

None.

[camargo]

Tested this locally and implemented a change on top of it in the UI. LGTM!

[kroffo]

Looks good to me overall. One minor issue to fix, and one comment to address, but nothing showstopping, so approved!

[mattdailis]

Looks good to me! I was a bit skeptical of the exception with a builder pattern, but then I looked at the generated code, and it looked quite elegant. Good job.

[pcrosemurgy]

I was a bit skeptical of the exception with a builder pattern, but then I looked at the generated code, and it looked quite elegant.

Good point, and I think it should get some skepticism.

I'm not too fond of using an exception as a required part of our UI <-> mission model workflow. The only alternative I could think of was to split getEffectiveArguments into 2 methods – and then complicate the already complex UI argument cobbling logic by requiring yet another endpoint to be hit.

I guess the argument for the pattern this PR uses is that we're not developing the mission model interface with UI concerns as the 1st priority, and that'll sometimes result in the UI relying on an exception to get ancillary data (such as returning default arguments when required args. are missing).