Netflix / genie

94%

master: 94%

LAST BUILD ON BRANCH v4.1.4

branch: v4.1.4

CHANGE BRANCH

x

Reset

• v4.1.4
• develop
• master
• 3.0.x
• 3.1.x
• 3.2.x
• 3.3.x
• v3.3.11
• v3.3.12
• c.n.genie.web.events.GenieEventBusImpl
• v4.0.0-rc.1
• v3.3.13
• v4.0.0-rc.2
• v3.3.15
• v3.3.16
• rollbackGradleChanges
• v3.3.18
• v4.0.0-rc.4
• v3.3.19
• v3.3.20
• v4.0.0-rc.5
• v4.0.0-rc.9
• v4.0.0-rc.10
• v4.0.0-rc.11
• v4.0.0-rc.12
• v4.0.0-rc.13
• v4.0.0-rc.14
• v4.0.0-rc.15
• v4.0.0-rc.16
• v4.0.0-rc.19
• v4.0.0-rc.20
• SlowBuildDebug
• v4.0.0-rc.21
• v4.0.0-rc.22
• v4.0.0-rc.23
• v4.0.0-rc.24
• v4.0.0-rc.25
• v4.0.0-rc.27
• v4.0.0-rc.28
• v4.0.0-rc.29
• v4.0.0-rc.31
• v4.0.0-rc.32
• v4.0.0-rc.33
• revert-923-GENIE-412-job-working-directory
• v4.0.0-rc.34
• v4.0.0-rc.35
• v4.0.0-rc.36
• dependabot/npm_and_yarn/genie-ui/npm-6.13.4
• v4.0.0-rc.37
• rpalcolea-patch-1
• v4.0.0-rc.38
• v4.0.0-rc.41
• v4.0.0-rc.42
• v4.0.0-rc.43
• v4.0.0-rc.44
• v4.0.0-rc.45
• v4.0.0-rc.46
• v4.0.0-rc.47
• v4.0.0-rc.48
• v4.0.0-rc.49
• v4.0.0-rc.50
• v4.0.0-rc.51
• v4.0.0-rc.52
• v4.0.0-rc.53
• v4.0.0-rc.54
• v4.0.0-rc.55
• v4.0.0-rc.56
• v4.0.0-rc.57
• v4.0.0-rc.58
• v4.0.0-rc.59
• v4.0.0-rc.60
• v4.0.0-rc.61
• v4.0.0-rc.63
• v4.0.0-rc.64
• v4.0.0-rc.65
• v4.0.0-rc.66
• v4.0.0-rc.67
• v4.0.0-rc.68
• v4.0.0-rc.69
• v4.0.0-rc.70
• v4.0.0-rc.71
• v4.0.0-rc.72
• v4.0.0-rc.73
• v4.0.0-rc.74
• v4.0.0-rc.75
• snapshot-test
• dev-snapshot
• v4.0.0-rc.77
• v4.0.0-rc.78
• v4.0.0-rc.80
• v4.0.0-rc.81
• v4.0.0-rc.82
• v4.0.0-rc.83
• v4.0.0-rc.84
• v4.0.0-rc.85
• v3.3.22
• v4.0.0-rc.86
• v4.0.0-rc.87
• v4.0.0-rc.88
• replace-bintray
• v4.0.0-rc.89
• v4.0.0-rc.90
• v4.0.0-rc.91
• v4.0.0-rc.92
• v4.0.0-rc.94
• v4.0.0-rc.95
• v4.0.0-rc.96
• v4.0.0-rc.97
• v4.0.0-rc.98
• v4.0.0
• 4.0.x
• v4.0.1
• v4.0.2
• v4.0.3
• v4.0.4
• v4.0.5
• v4.0.6
• v4.1.0
• 4.1.x
• v4.1.1
• v4.1.2
• v4.1.3
• v4.1.5
• v4.2.0
• 4.2.x
• v4.1.6
• v4.2.1
• v4.2.2
• v4.3.0

Build # 3204

Build Type

push

travis-ci-com

Committed by tgianos

Commit Message

Fix exposing inconsistency in job status outside of persistence API

Within job launch logic there was a helper method which would query the job status and based on the returned value proceed with some logic to either update it or fall back to other logic. This works ok if all requests to the persistence service implementation go to a single cosistent backend. If, however, read only queries go to a read replica which may have lag or some other implementation entirely this breaks down without the service actually knowing why or how.

Moving the logic for this behind the persistence API and letting the launch service only act the returned job status from the source of truth api should fix this problem.

Run Details

28 of 28 new or added lines in 2 files covered. (100.0%)

13429 of 14321 relevant lines covered (93.77%)

0.94 hits per line