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

TASK_EXECUTION_ID not propagated by SCDF in entryPointStyle boot #5917

Open
jnt0r opened this issue Aug 29, 2024 · 5 comments
Open

TASK_EXECUTION_ID not propagated by SCDF in entryPointStyle boot #5917

jnt0r opened this issue Aug 29, 2024 · 5 comments
Assignees
Labels
status/need-feedback Calling participant to provide feedback

Comments

@jnt0r
Copy link

jnt0r commented Aug 29, 2024

Description:
When changing the entryPointStyle to boot the Variable SPRING_CLOUD_TASK_EXECUTIONID is not present in the SPRING_APPLICATION_JSON environment variable. When using the shell entryPointStyle, the ENV SPRING_CLOUD_TASK_EXECUTIONID is present with the correct value.
This results in the launched task to generate new TaskExecutionId and therefore the id in SCDF and the TASK do not match. Also there are always 2 task executions when launching a single task.

Release versions:
{ "versions": { "implementation": { "name": "spring-cloud-dataflow-server", "version": "2.11.3" }, "core": { "name": "Spring Cloud Data Flow Core", "version": "2.11.3" }, "dashboard": { "name": "Spring Cloud Dataflow UI", "version": "3.4.3" }, "shell": { "name": "Spring Cloud Data Flow Shell", "version": "2.11.3", "url": "https://repo.maven.apache.org/maven2/org/springframework/cloud/spring-cloud-dataflow-shell/2.11.3/spring-cloud-dataflow-shell-2.11.3.jar" } }, "features": { "streams": true, "tasks": true, "schedules": true, "monitoringDashboardType": "NONE" }, "runtimeEnvironment": { "appDeployer": { "deployerImplementationVersion": "2.11.3", "deployerName": "Spring Cloud Skipper Server", "deployerSpiVersion": "2.11.3", "javaVersion": "21.0.3", "platformApiVersion": "", "platformClientVersion": "", "platformHostVersion": "", "platformSpecificInfo": { "default": "kubernetes" }, "platformType": "Skipper Managed", "springBootVersion": "2.7.18", "springVersion": "5.3.34" }, "taskLaunchers": [ { "deployerImplementationVersion": "unknown", "deployerName": "KubernetesTaskLauncher", "deployerSpiVersion": "unknown", "javaVersion": "21.0.3", "platformApiVersion": "v1", "platformClientVersion": "unknown", "platformHostVersion": "unknown", "platformSpecificInfo": { "namespace": "XXX", "master-url": "XXX" }, "platformType": "Kubernetes", "springBootVersion": "2.7.18", "springVersion": "5.3.34" } ] }, "monitoringDashboardInfo": { "url": "", "source": "default-scdf-source", "refreshInterval": 15 }, "security": { "isAuthentication": false, "isAuthenticated": false, "username": null, "roles": [] }, "git": { "commit": "2183849" } }

Steps to reproduce:
switch to boot entryPointStyle and start a task.

The resulting value of SPRING_APPLICATION_JSON:
{ "management.metrics.tags.service": "task-application", "spring.datasource.url": "XXX", "spring.datasource.driverClassName": "XXX", "management.metrics.tags.application": "${spring.cloud.task.name:unknown}-${spring.cloud.task.executionid:unknown}", "spring.cloud.task.initialize-enabled": "false", "spring.batch.jdbc.table-prefix": "BOOT3_BATCH_", "spring.cloud.task.schemaTarget": "boot3", "spring.cloud.task.name": "XXX", "spring.cloud.task.tablePrefix": "BOOT3_TASK_", "spring.cloud.deployer.bootVersion": "3" }

@github-actions github-actions bot added the status/need-triage Team needs to triage and take a first look label Aug 29, 2024
@corneil corneil self-assigned this Aug 30, 2024
@corneil
Copy link
Contributor

corneil commented Aug 30, 2024

From my tests is seems that when using boot or exec the property spring.cloud.task.executionid added as argument regardless of the entryPointStyle.
Only with shell is it added as an environmental variable.

It seems that in the case of boot the SPRING_APPLICATION_JSON has already been created when we obtain new id and add argument.

@cppwfs
Copy link
Contributor

cppwfs commented Sep 30, 2024

Closing this issue due to inactivity. If this issue needs to be reopened, please leave a comment. Thank you!

@cppwfs cppwfs closed this as completed Sep 30, 2024
@cppwfs cppwfs added status/need-feedback Calling participant to provide feedback and removed status/need-triage Team needs to triage and take a first look labels Sep 30, 2024
@jnt0r
Copy link
Author

jnt0r commented Sep 30, 2024

Can this be reopened? @corneil identified the bug already. I didn't have time to dig into this and fix it myself, unfortunately.

@github-actions github-actions bot added for/team-attention For team attention and removed status/need-feedback Calling participant to provide feedback labels Sep 30, 2024
@cppwfs cppwfs reopened this Sep 30, 2024
@corneil
Copy link
Contributor

corneil commented Nov 12, 2024

The workaround is to avoid the boot entrypoint style for now. The default in when spring-boot plugin is to use the exec style and not provide a SPRING_APPLICATION_JSON with properties.

@github-actions github-actions bot added status/need-feedback Calling participant to provide feedback and removed for/team-attention For team attention labels Nov 12, 2024
@corneil
Copy link
Contributor

corneil commented Nov 12, 2024

@jnt0r Did you provide a SPRING_APPLICATION_JSON property to the deployment as environmental variable?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status/need-feedback Calling participant to provide feedback
Projects
None yet
Development

No branches or pull requests

3 participants