[jwrosewell]

Adds a test that GeoLocationCloud builds and gives empty data, with no error, when the Resource Key holds no location product, and logs that once. #54 made every Cloud Aspect Engine here behave that way and tested it for IP Intelligence and Device Detection, and its body said GeoLocationCloud had no such test because none ran without a live service. This one replaces the cloud service, so it needs no key.

What the specification says

cloud-aspect-engine.md, Start-up activity, at 6570727d:

Once the Cloud Request Engine's discovery has completed, a Resource Key can be valid and still include no product that holds a particular Cloud Aspect Engine's Properties. That is not a definitive configuration error, so the Cloud Aspect Engine MUST NOT fail the Pipeline build. It builds with empty Property metadata and MUST log the missing product once per Cloud Aspect Engine instance, at warning level, naming its Data Key. It MUST NOT log the missing product again on each response.

and under Processing:

Where the response JSON has no portion for the Engine's Data Key, the Cloud Aspect Engine leaves the Element Data without values and raises no error.

What changed

location/tests/MissingProductTests.php, added to location's Integration suite in location/phpunit.xml. It builds a Pipeline with GeoLocationPipelineBuilder and an HttpClient that answers as the cloud service would for a Resource Key holding only a device product, once with the 51Degrees provider (Data Key location) and once with Digital Element (location_digitalelement). Each time it processes three requests with a latitude and longitude, and checks that no request has an error, that each gives empty location data, and that exactly one log entry names the Data Key, at warning level. No package code changes.

Runs

Each throwaway run installs from the repository root and runs the test file alone, on Ubuntu with PHP 8.1 and 8.5 and on Windows with PHP 8.3. PHP 8.0 is left out because the root composer.json cannot be installed there, fiftyone.pipeline.did needing PHP 8.1.

• Red, run 43584235591 on d5e3f79, failure. Its tree is the code before #54, being 08f7bef, with this test file and the throwaway workflow added. In every job both cases ended with the exception "Location data was not available. Check that this key is authorised for geolocation data", which GeoLocationCloud threw on each request before Build a Cloud Aspect Engine whose product is missing, and log the missing product once #54.
• Green, run 43584225542 on 843e3b6, success. Its parent is the head 2856582d on rc 36b71fd. Both cases passed, 16 assertions, with PHPUnit 10.5.67 on PHP 8.1, 13.4.7 on PHP 8.5 and 12.5.44 on Windows PHP 8.3. On PHP 8.5 PHPUnit also counted four deprecations, as it did in the red run on the older code, so they come from code the test reaches rather than from this change.
• Full build, run 43672935533 on the head 2856582, success, with rc 49ea15c merged in, which holds #117 and its move of cxx to 0312236c. The run printed 9 of 9 Setting 'PullRequestSha' lines on 2856582, and Configure printed "Left out 5 macOS entries". All eight jobs passed, Ubuntu with PHP 7.4 and 8.0 to 8.5 and Windows with PHP 8.3. In the Ubuntu PHP 8.3 job, on ubuntu-26.04, the Unit suites passed 1,044 tests (pipeline/core 509 with 1 skipped, pipeline/engines 9, pipeline/cloudrequestengine 90, pipeline/did 192, pipeline/translation 22, pipeline/derivedproperty 52, device-detection/cloud 29, device-detection/onpremise 89 and ip-intelligence 52) and the Integration suites 134 (pipeline/cloudrequestengine 6, device-detection/cloud 36, location 18 and ip-intelligence 74).

macOS was left out of this draft's full build under the 9 November decision. The rc head is built with macOS before it merges into main.

What remains

Nothing for this test. The Cloud Request Engine still fetches what the Resource Key holds on the first request, not at build, until #128 moves that to the build, and #136 has each cloud aspect engine take its properties when it joins the Pipeline. Even with both, the missing product is logged only in processInternal, on the first request, so the warning is written then, as #54 said. #146 tracks that warning.