-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Deploy stage failing with "NOT_STARTED" status on synthetic before stage #5257
Labels
Comments
@spinnakerbot assign-issue @pdelagrave |
User @pdelagrave cannot be assigned in this repo (spinnaker/spinnaker). Are they in the correct org/team? |
pdelagrave
pushed a commit
to pdelagrave/orca
that referenced
this issue
Jan 10, 2020
Fixes spinnaker/spinnaker#5257 The `Stage` constructor was keeping `refId`, `startTimeExpiry` and `requisiteStageRefIds` from the context map argument in its internal context map. This caused issues when a parent stage's context was used to create a child stage, as these entries aren't expected to be inherited. This wasn't a problem for a long time because these values were accidentally removed by the side effect of `StartStageHandler#shouldSkip`. `shouldSkip()` uses `objectMapper.convertValue()` on a stage context expecting to have a cloned map returned. A long standing design/documentation issue with Jackson made `convertValue()` return the input parameter as is instead of converting/cloning it. This made every `Stage` passing through `StartStageHandler.handle()` having their context map indirectly 'corrected' and persisted. An upcoming upgrade to Spring Boot 2.2 comes with Jackson 2.10 where `objectMapper.convertValue()` has a new behaviour and would make `shouldSkip()` fail to silently 'correct' the stages context map. FasterXML/jackson-databind#2220 `BakeStageSpec` was validating `context['refId']` on the generated contexts but the contexts aren't Stages yet; once a context is made into a Stage and added to the graph (`graph.add`) it will have its `refId` generated based on the parent refId; which isn't under test in that spec.
mergify bot
added a commit
to spinnaker/orca
that referenced
this issue
Jan 21, 2020
Fixes spinnaker/spinnaker#5257 The `Stage` constructor was keeping `refId`, `startTimeExpiry` and `requisiteStageRefIds` from the context map argument in its internal context map. This caused issues when a parent stage's context was used to create a child stage, as these entries aren't expected to be inherited. This wasn't a problem for a long time because these values were accidentally removed by the side effect of `StartStageHandler#shouldSkip`. `shouldSkip()` uses `objectMapper.convertValue()` on a stage context expecting to have a cloned map returned. A long standing design/documentation issue with Jackson made `convertValue()` return the input parameter as is instead of converting/cloning it. This made every `Stage` passing through `StartStageHandler.handle()` having their context map indirectly 'corrected' and persisted. An upcoming upgrade to Spring Boot 2.2 comes with Jackson 2.10 where `objectMapper.convertValue()` has a new behaviour and would make `shouldSkip()` fail to silently 'correct' the stages context map. FasterXML/jackson-databind#2220 `BakeStageSpec` was validating `context['refId']` on the generated contexts but the contexts aren't Stages yet; once a context is made into a Stage and added to the graph (`graph.add`) it will have its `refId` generated based on the parent refId; which isn't under test in that spec. Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
KathrynLewis
pushed a commit
to KathrynLewis/orca
that referenced
this issue
Jan 31, 2021
Fixes spinnaker/spinnaker#5257 The `Stage` constructor was keeping `refId`, `startTimeExpiry` and `requisiteStageRefIds` from the context map argument in its internal context map. This caused issues when a parent stage's context was used to create a child stage, as these entries aren't expected to be inherited. This wasn't a problem for a long time because these values were accidentally removed by the side effect of `StartStageHandler#shouldSkip`. `shouldSkip()` uses `objectMapper.convertValue()` on a stage context expecting to have a cloned map returned. A long standing design/documentation issue with Jackson made `convertValue()` return the input parameter as is instead of converting/cloning it. This made every `Stage` passing through `StartStageHandler.handle()` having their context map indirectly 'corrected' and persisted. An upcoming upgrade to Spring Boot 2.2 comes with Jackson 2.10 where `objectMapper.convertValue()` has a new behaviour and would make `shouldSkip()` fail to silently 'correct' the stages context map. FasterXML/jackson-databind#2220 `BakeStageSpec` was validating `context['refId']` on the generated contexts but the contexts aren't Stages yet; once a context is made into a Stage and added to the graph (`graph.add`) it will have its `refId` generated based on the parent refId; which isn't under test in that spec. Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Issue Summary:
Post merge of #3333 pipelines with a
deploy
stage are failing.It appears that the synthetic stage that is intended to run prior to the deploy stage fails to start and is left with the status
NOT_STARTED
. After a bit of debugging, it seems this is tied to therequisiteStageRefIds
array containing the id of an earlier stage in the pipeline. I tested this against 1.17 and found that the same pipeline generates an emptyrequisiteStageRefIds
array for the synthetic stage. In that case, only the parentdeploy
stage lists the prior stage in itsrequisiteStageRefIds
and the pipeline executes correctly.Here is the sample JSON for what the synthetic stage looks like on master:
And for how it appears on 1.17
The
NOT_STARTED
status for the synthetic stage causes the parent deploy stage to be marked asTERMINAL
and the execution to fail. The orca log reflects this with:ERROR 247858 --- [ handlers-19] c.n.s.o.q.handler.CompleteStageHandler : [] Unhandled condition for stage 01DWFPSBYCR01SK1YZPY6JN3B6 of com.netflix.spinnaker.orca.pipeline.model.Execution@af536b3a.id, marking as TERMINAL. syntheticStatuses=[NOT_STARTED], taskStatuses=[SUCCEEDED], planningStatus=[], afterStageStatuses=[]
Cloud Provider(s):
GCE, EC2
Environment:
Master
Steps to Reproduce:
This can be reproduced by creating a pipeline with a deploy stage that targets gce or ec2. A simple pipeline for reproducing:
The text was updated successfully, but these errors were encountered: