Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Launching the same CTR instance will now succeed #5415

Merged
merged 1 commit into from
Jul 27, 2023

Conversation

cppwfs
Copy link
Contributor

@cppwfs cppwfs commented Jul 24, 2023

Scenario
CTR launch with simple conditional statement that contains both Boot2 and Boot3 apps. Relaunch the CTR again it should succeed by default.

app register --bootVersion 3 --name timestamp3 --uri maven://io.spring:timestamp-task:3.0.0 --type task
task create --name ctrseq --definition "timestamp && timestamp3"
task launch --name ctrseq
task list
task execution list
task execution status --id ctrseq
task launch --name ctrseq
task execution list
task execution status --id ctrseq

The cause is SCDF stores the taskPrefix using both the composed-task-app-properties and the properties. While this works for the first execution,
The second execution fails because it picks up a duplicate property for the taskPrefix. This is because on the first execution, it is stored in the manifest as a base64 value.
So the solution is not to re-add the taskPrefix app properties and use just the composed-task-app-properties, which is used by CTR to determine which prefix to use and will be passed to the child app.

We can discuss if there is a better solution.

**Scenario**
CTR launch with simple conditional statement that contains both Boot2 and Boot3 apps.  Relaunch the CTR again it should succeed by default.

```
app register --bootVersion 3 --name timestamp3 --uri maven://io.spring:timestamp-task:3.0.0 --type task
task create --name ctrseq --definition "timestamp && timestamp3"
task launch --name ctrseq
task list
task execution list
task execution status --id ctrseq
task launch --name ctrseq
task execution list
task execution status --id ctrseq
```
The cause is SCDF stores the taskPrefix using both the composed-task-app-properties and the properties.   While this works for the first execution,
The second execution fails because it picks up a duplicate property for the taskPrefix.   This is because on the first execution, it is stored in the manifest as a base64 value.
So the solution is not to re-add the taskPrefix app properties and use just the composed-task-app-properties, which is used by CTR to determine which prefix to use and will be passed to the child app.
@markpollack markpollack requested a review from corneil July 25, 2023 15:26
@corneil corneil merged commit cfbcf70 into spring-cloud:main Jul 27, 2023
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants