Summary
The nightly has failed for a week+ (08-22 onward) on the cloud web example test. GettingStartedWebCloudTest.testWebCloud gets HTTP 503 instead of 200, failing every Nightly Publish / Test leg across all platforms. The evidence points to a resource-key entitlement problem, not a code bug or a cloud outage: the TestResourceKey this repo uses is not (or no longer) provisioned for the IP-Intelligence cloud product, so the cloud example's pipeline fails to build at startup.
- Example failed run: 33040307322 (recurs 08-23, 08-26, 08-27).
Symptom
Running fiftyone.ipintelligence.examples.web.GettingStartedWebCloudTest
[ERROR] testWebCloud ... <<< FAILURE!
java.lang.AssertionError: Expected HTTP 200 OK response expected:<200> but was:<503>
at GettingStartedWebCloudTest.testWebCloud(GettingStartedWebCloudTest.java:94)
BUILD FAILURE - ip-intelligence-java-examples.web.getting-started.cloud
Fails on every platform/Java-version leg simultaneously.
Analysis
The 503 is Jetty's, not the cloud's. GettingStartedWebCloud's request path returns 200 on success and 500 in its catch block, so a request cannot produce a 503. 503 is what embedded Jetty serves when the servlet / PipelineFilter fails to initialise - i.e. the cloud pipeline built from WEB-INF/51Degrees-Cloud.xml threw at startup. The test's 503 therefore means "the cloud example never came up," and the real cause is whatever made that pipeline build throw.
Only the cloud example touches the cloud, and it is the only one that fails. Reactor summary from the failing run:
Getting Started :: OnPrem SUCCESS
Getting Started :: Mixed SUCCESS
Getting Started :: Cloud FAILURE <- 503
Getting Started :: Cloud Mixed SKIPPED (skipped after Cloud failed)
"Mixed" is not cloud - its config is DeviceDetectionHashEngine + IPIntelligenceOnPremiseEngine, both on-premise using local data files - so it passing says nothing about the cloud. The cloud example's pipeline is:
<Element><ResourceKey>${TestResourceKey}</ResourceKey><BuilderName>CloudRequestEngine</BuilderName></Element>
<Element><BuilderName>IPIntelligenceCloudEngine</BuilderName></Element>
At startup CloudRequestEngine calls cloud.51degrees.com to validate the key and fetch the IP-Intelligence properties that IPIntelligenceCloudEngine needs. That failing is what throws and takes the servlet down.
Not a code/example bug: the example is unchanged and the on-prem / mixed variants pass on the same build - only the variant that authenticates a key against the cloud fails.
Not a cloud outage: ip-intelligence-dotnet's FiftyOne.IpIntelligence.CloudTests hit the same cloud.51degrees.com for IP-Intelligence and passed on 08-27. The only cloud-path difference between dotnet (works) and java (503) is the per-repo TestResourceKey secret.
Root cause
The TestResourceKey used by ip-intelligence-java is not provisioned for the IP-Intelligence cloud product (or its entitlement lapsed). CloudRequestEngine / IPIntelligenceCloudEngine cannot build for a key without IPI properties, so the cloud example's servlet fails to initialise and Jetty returns 503.
Fix
- On the 51Degrees cloud configuration portal, check the
TestResourceKey secret used by this repo and ensure it has the IP-Intelligence properties enabled. Compare against ip-intelligence-dotnet's working key.
- Re-provision that key for IPI cloud (or replace the secret with an entitled key), then re-run the nightly.
Getting the literal cloud error (optional confirmation)
The exact startup exception is written to web/getting-started.cloud/target/surefire-reports/*.txt on the runner but this pipeline does not upload it. To capture it: upload **/surefire-reports/** as an artifact on failure, or run the cloud example locally with that key and read the startup exception - it will name the key/property problem directly.
Acceptance criteria
Summary
The nightly has failed for a week+ (08-22 onward) on the cloud web example test.
GettingStartedWebCloudTest.testWebCloudgets HTTP 503 instead of 200, failing everyNightly Publish / Testleg across all platforms. The evidence points to a resource-key entitlement problem, not a code bug or a cloud outage: theTestResourceKeythis repo uses is not (or no longer) provisioned for the IP-Intelligence cloud product, so the cloud example's pipeline fails to build at startup.Symptom
Fails on every platform/Java-version leg simultaneously.
Analysis
The 503 is Jetty's, not the cloud's.
GettingStartedWebCloud's request path returns200on success and500in its catch block, so a request cannot produce a 503. 503 is what embedded Jetty serves when the servlet /PipelineFilterfails to initialise - i.e. the cloud pipeline built fromWEB-INF/51Degrees-Cloud.xmlthrew at startup. The test's 503 therefore means "the cloud example never came up," and the real cause is whatever made that pipeline build throw.Only the cloud example touches the cloud, and it is the only one that fails. Reactor summary from the failing run:
"Mixed" is not cloud - its config is
DeviceDetectionHashEngine+IPIntelligenceOnPremiseEngine, both on-premise using local data files - so it passing says nothing about the cloud. The cloud example's pipeline is:At startup
CloudRequestEnginecallscloud.51degrees.comto validate the key and fetch the IP-Intelligence properties thatIPIntelligenceCloudEngineneeds. That failing is what throws and takes the servlet down.Not a code/example bug: the example is unchanged and the on-prem / mixed variants pass on the same build - only the variant that authenticates a key against the cloud fails.
Not a cloud outage:
ip-intelligence-dotnet'sFiftyOne.IpIntelligence.CloudTestshit the samecloud.51degrees.comfor IP-Intelligence and passed on 08-27. The only cloud-path difference between dotnet (works) and java (503) is the per-repoTestResourceKeysecret.Root cause
The
TestResourceKeyused by ip-intelligence-java is not provisioned for the IP-Intelligence cloud product (or its entitlement lapsed).CloudRequestEngine/IPIntelligenceCloudEnginecannot build for a key without IPI properties, so the cloud example's servlet fails to initialise and Jetty returns 503.Fix
TestResourceKeysecret used by this repo and ensure it has the IP-Intelligence properties enabled. Compare againstip-intelligence-dotnet's working key.Getting the literal cloud error (optional confirmation)
The exact startup exception is written to
web/getting-started.cloud/target/surefire-reports/*.txton the runner but this pipeline does not upload it. To capture it: upload**/surefire-reports/**as an artifact on failure, or run the cloud example locally with that key and read the startup exception - it will name the key/property problem directly.Acceptance criteria
TestResourceKeyfor ip-intelligence-java confirmed provisioned for IP-Intelligence cloud (parity with the dotnet key).GettingStartedWebCloudTest.testWebCloudreturns 200 and the nightlyPublish / Testlegs pass.