nishita-09 commented on code in PR #1000:
URL:
https://github.com/apache/flink-kubernetes-operator/pull/1000#discussion_r3093083906
##########
flink-kubernetes-operator/src/main/java/org/apache/flink/kubernetes/operator/reconciler/sessionjob/SessionJobReconciler.java:
##########
@@ -111,10 +111,14 @@ public void deploy(
@Override
protected boolean cancelJob(FlinkResourceContext<FlinkSessionJob> ctx,
SuspendMode suspendMode)
throws Exception {
+ var resource = ctx.getResource();
+ ctx.getConfigManager()
+ .invalidateRuntimeConfig(
Review Comment:
@Dennis-Mircea I was thinking of some scenarios, while I do understand in
the current set of things we would not need this explicitly since TTL would
take care of it eventually. I feel this could be a real use case in scenarios
where same jobId is used in recovery/cancellation to run the job with updated
config -> ensure invalidation of the job whenever cancel/resubmit is called
should be good guardrail.
I totally agree with the point that if we call `invalidateRuntimeConfig` in
cancelJob, it needs to be included in other valid scenarios as well.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
