avoid panic on bad Kong config #338
Conversation
if the Kong client fails to connect correctly, the RunWhenEnterprise function panics when reading the (missing) configuration. Since this is a common failure in CI tests, this PR adds sanity tests to avoid the panic and get better failure logs.
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #338 +/- ##
==========================================
- Coverage 52.75% 52.73% -0.03%
==========================================
Files 69 69
Lines 5093 5103 +10
==========================================
+ Hits 2687 2691 +4
- Misses 1832 1836 +4
- Partials 574 576 +2
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ View full report in Codecov by Sentry. |
|
depends on #337 to fix (remove) the |
There was a problem hiding this comment.
Should we not just
rawConfiguration, ok := info["configuration"]
if !ok {
t.Fatal("could not retrieve Kong configuration")
}
configuration := rawConfiguration.(map[string]interface{})
as a simpler approach? It seems like the first will imply the latter two are also going to fail.
That aside, what's happening here where this isn't failing earlier? Shouldn't we get some failure after the client request? Are we getting some issue where the root responds successfully, but with an empty response?
yes, that should work too
not sure how it happens, but it does. my guess is that sometimes kong isn't correctly loaded by the GiHub actions and the connection handshake doesn't complete. the logs definitely point to a panic that happens here when there's no configuration. |
if the Kong client fails to connect correctly, the RunWhenEnterprise function panics when reading the (missing) configuration.
Since this is a common failure in CI tests, this PR adds sanity tests to avoid the panic and get better failure logs.