Found by probing the endpoint against real Vuforia with a throwaway database. Unlike #3363 these are not fixed, because fixing them is a design choice rather than a correction.
What real Vuforia returns
https://guacamole-targetstore-production-targets.s3.us-west-1.amazonaws.com/reports/{database_id}/{name}.csv
?X-Amz-Security-Token=...
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Date=20260808T210052Z
&X-Amz-SignedHeaders=host
&X-Amz-Credential=.../20260808/us-west-1/s3/aws4_request
&X-Amz-Expires=604799
&X-Amz-Signature=...
Two things differ from the mock beyond the host, which is unavoidable.
The file name encodes the month, and differently per month
- Current month:
2026-08-08-21.csv, which is the date and the hour.
- Previous month:
2026-07.csv, which is the month only.
So a caller which requests the current month twice in the same hour gets the same file name, and in a different hour gets a different one. The mock names every report after an opaque report ID, so nothing about the requested month is recoverable from the URL, and two requests for the same month never collide.
Code which parses the file name out of the URL, or which deduplicates reports by URL, behaves differently against the mock.
The URL is signed and expires
X-Amz-Expires=604799 is one second under seven days. The mock's URL has no query parameters at all and never expires. Code which stores a URL and refetches it later cannot discover through the mock that the URL goes stale, nor that tampering with it fails a signature check.
Also unresolved: the 404-until-ready behaviour
The mock returns 404 until processing_time_seconds has elapsed, then 200. That was modelled on the documentation, which says a report takes between a few seconds and one hour to generate.
In this observation the report was ready immediately. The request returned at 21:00:52 and the object's Last-Modified was 21:00:54, and a fetch at 21:01:28 returned 200. No 404 was ever observed, so the mock's central download behaviour is still unverified, and it is now unclear whether a not-ready report 404s, or whether S3 returns its own NoSuchKey error document, which is XML rather than the empty body the mock returns.
This changes the premise of #3360, which assumed the download could not be exercised in a test because of the documented hour. It plainly can. What is hard is provoking the not-ready state at all.
Suggested resolution
Decide, and record the decision, for each of:
- Whether the mock should name report files after the requested month, following the two real forms. This is cheap and makes the URL informative, at the cost of colliding requests within an hour, which real Vuforia also does.
- Whether the mock's URL should carry expiry, so that callers can test their handling of a stale URL. A real signature cannot be reproduced, but an
X-Amz-Expires-like parameter which the mock honours would be testable.
- What a not-ready report actually returns, which needs another probe that manages to catch a report before it is generated.
Whatever is decided, differences-to-vws.rst should describe the real URL shape rather than describing the mock's as merely lacking query parameters.
Found by probing the endpoint against real Vuforia with a throwaway database. Unlike #3363 these are not fixed, because fixing them is a design choice rather than a correction.
What real Vuforia returns
Two things differ from the mock beyond the host, which is unavoidable.
The file name encodes the month, and differently per month
2026-08-08-21.csv, which is the date and the hour.2026-07.csv, which is the month only.So a caller which requests the current month twice in the same hour gets the same file name, and in a different hour gets a different one. The mock names every report after an opaque report ID, so nothing about the requested month is recoverable from the URL, and two requests for the same month never collide.
Code which parses the file name out of the URL, or which deduplicates reports by URL, behaves differently against the mock.
The URL is signed and expires
X-Amz-Expires=604799is one second under seven days. The mock's URL has no query parameters at all and never expires. Code which stores a URL and refetches it later cannot discover through the mock that the URL goes stale, nor that tampering with it fails a signature check.Also unresolved: the 404-until-ready behaviour
The mock returns 404 until
processing_time_secondshas elapsed, then 200. That was modelled on the documentation, which says a report takes between a few seconds and one hour to generate.In this observation the report was ready immediately. The request returned at 21:00:52 and the object's
Last-Modifiedwas 21:00:54, and a fetch at 21:01:28 returned 200. No 404 was ever observed, so the mock's central download behaviour is still unverified, and it is now unclear whether a not-ready report 404s, or whether S3 returns its ownNoSuchKeyerror document, which is XML rather than the empty body the mock returns.This changes the premise of #3360, which assumed the download could not be exercised in a test because of the documented hour. It plainly can. What is hard is provoking the not-ready state at all.
Suggested resolution
Decide, and record the decision, for each of:
X-Amz-Expires-like parameter which the mock honours would be testable.Whatever is decided,
differences-to-vws.rstshould describe the real URL shape rather than describing the mock's as merely lacking query parameters.