2.7 -> 2.8 properties not rendered on second launch in 2.8.x

[cppwfs]

Follow instructions enumerated in this doc for creating test case in 2.7->2.8:
https://docs.google.com/document/d/1SQh9gm1GjMVdewDaY5D21ytMmS8QWQXxmMZ49jAMAQM/edit#

All ctr2 apps launch with properties in 2.8.x properly. But when I go back to relaunch for a 2nd time in 2.8.x t3 properties after the first property are now missing.

[cppwfs]

In the instructions above we see that the first 2 executions work as expected. Its the 3rd launch we see that the 2nd property is truncated.
Rerunning this on SCDF 2.7.2 following the instructions above we see the 3rd launch will have the following properties

app.ctr2-t3.app.timestamp.timestamp.format=MM
app.composed-task-runner.composed-task-properties=app.ctr2-t1.app.timestamp.timestamp.format=YYYY

It does work, but its odd on how it stores the properties.

[cppwfs]

This looks like it is a 2.8.x UI issue. The steps above can even be executed on 2.8.x no migration necessary.
If we look at the data returned when requesting the manifest we see that both values are there, however the builder trunctates the property that is not set as a part of the app.composed-task-runner.composed-task-properties.
Here is the manifest returned from the server:

// 20210602194228
// http://localhost:9393/tasks/definitions/ctr2?manifest=true

{
  "name": "ctr2",
  "dslText": "<t1: timestamp || t2: timestamp> && t3: timestamp",
  "description": "",
  "composed": true,
  "composedTaskElement": false,
  "lastTaskExecution": {
    "executionId": 14,
    "exitCode": 0,
    "taskName": "ctr2",
    "startTime": "2021-06-02T19:33:16.000-0400",
    "endTime": "2021-06-02T19:33:37.000-0400",
    "exitMessage": null,
    "arguments": [
      "--spring.cloud.task.executionid=14",
      "--spring.cloud.data.flow.taskappname=composed-task-runner"
    ],
    "jobExecutionIds": null,
    "errorMessage": null,
    "externalExecutionId": "ctr2-2b322e8a-7ee4-463a-9e49-65a0ce1aef0f",
    "parentExecutionId": null,
    "resourceUrl": "org.springframework.cloud:spring-cloud-dataflow-composed-task-runner:jar:2.7.2",
    "appProperties": {
      "management.metrics.tags.service": "task-application",
      "spring.datasource.username": "******",
      "spring.datasource.url": "******",
      "spring.datasource.driverClassName": "org.mariadb.jdbc.Driver",
      "management.metrics.tags.application": "${spring.cloud.task.name:unknown}-${spring.cloud.task.executionid:unknown}",
      "platform-name": "default",
      "spring.cloud.task.name": "ctr2",
      "composed-task-properties": "app.ctr2-t1.app.timestamp.timestamp.format=YYYY",
      "graph": "<ctr2-t1 || ctr2-t2> && ctr2-t3",
      "spring.datasource.password": "******"
    },
    "deploymentProperties": {
      "app.ctr2-t3.app.timestamp.timestamp.format": "MM",
      "app.composed-task-runner.composed-task-properties": "app.ctr2-t1.app.timestamp.timestamp.format=YYYY"
    },
    "platformName": null,
    "taskExecutionStatus": "COMPLETE"
  },
  "status": "COMPLETE",
  "_links": {
    "self": {
      "href": "http://localhost:9393/tasks/definitions/ctr2"
    }
  }
}

[jvalkeal]

I think we need to handle:

"app.composed-task-runner.composed-task-properties": "app.ctr1-t1.app.timestamp.timestamp.format=yyyy"

as it's always coming back when you relaunch.
Maybe not show it if

"app.t1.timestamp.format": "yyyy",

as new property is in place.

It's kinda annoying issue as long as we still have ctr task names in any of a properties and we haven't yet fully migrated away.

[sabbyanandan]

This has been fixed by @jvalkeal; still needs validation from @cppwfs to close the issue.

[sabbyanandan]

I will take this.

[sabbyanandan]

Launched the CTR test scripts a few times with adjustments to app properties and args. The app properties are correctly persisted on every subsequent launch.