After an update, tracking_rating reports the new image's rating while the target is still processing

[adamtheturtle]

What happens

ImageTarget measures processing progress from two different fields.

status measures from last_modified_date:

        time_since_change = now - self.last_modified_date
        if time_since_change <= processing_time:
            return TargetStatuses.PROCESSING.value

tracking_rating measures from upload_date:

        time_since_upload = now - self.upload_date
        # The real VWS seems to give -1 for a short time while processing, then
        # the real rating, even while it is still processing.
        if time_since_upload <= pre_rating_time:
            return -1

update_target refreshes last_modified_date and leaves upload_date alone, which is correct for what those fields mean. The consequence is that after an update the two properties disagree about when processing started.

Adding a target, then updating it with a different image. Image A rates 1, image B rates 0, and processing_time_seconds is 3:

standalone rating of image A = 1
standalone rating of image B = 0
settled:  status=success    rating=1
  +0s   status=processing   rating=0
  +1s   status=processing   rating=0
  +2s   status=processing   rating=0
  +3s   status=failed       rating=0

Two things at +0s. The -1 window never happens — it is anchored to upload_date, so it can only ever occur once in a target's life, right after the original upload. And the rating is already 0, which is the new image's rating, published the instant the update is accepted.

For comparison, the same target after its original upload does have the window, so the intended behaviour works for adds:

after ADD:
   t~0.0s  status=processing tracking_rating=-1
   t~1.2s  status=processing tracking_rating=1
   t~2.2s  status=success    tracking_rating=1

Why it matters

The mock is reporting the result of processing an image it is simultaneously claiming not to have processed yet. Real Vuforia cannot do that — computing the rating is what the processing state is for — so it must return either -1 or the previous image's rating during a post-update reprocess.

The practical impact is on polling code. Anyone who waits for an update to be processed by watching tracking_rating leave -1, rather than by watching status, will see it work against the mock and hang against real Vuforia. That is a narrower audience than watching status, but it is exactly the sort of thing the -1 window was implemented to let people test.

What is unknown

Which value real Vuforia reports during a post-update reprocess. The comment in target.py records an observation about uploads only:

The real VWS seems to give -1 for a short time while processing, then the real rating, even while it is still processing.

Whether an update produces a fresh -1 window, keeps the old rating, or does something else has not been observed. That is the thing to find out before fixing, because it decides between two different fixes.

Suggested resolution

Give ImageTarget a single field for "when the current image started processing", set at creation and refreshed by update_target when the image changes, and have both status and tracking_rating read it. last_modified_date and upload_date then keep their existing meanings for the API responses.

That change alone makes -1 recur after an update. Whether the rating during the window should be -1 or the old image's rating needs the verification above; the mock cannot currently express "the old rating" at all, since the rater is applied to whatever image_value currently holds.

A verified fake test would be an update to an image with a known different rating, polled during the processing window. tests/mock_vws/test_update_target.py is the natural home.

[adamtheturtle]

There is already a verified fake test in the right place, and it is worth naming because it shows precisely where the gap is.

tests/mock_vws/test_update_target.py::TestImage::test_rating_can_change covers an update which changes the rating, across all three backends including real Vuforia. But it calls wait_for_target_processed before reading the rating, both before and after the update:

        vws_client.update_target(target_id=target_id, image=high_quality_image)

        vws_client.wait_for_target_processed(target_id=target_id)
        target_details = vws_client.get_target_record(target_id=target_id)
        assert target_details.status == TargetStatuses.SUCCESS
        new_tracking_rating = target_details.target_record.tracking_rating

So it only ever observes the settled state. The processing window itself — the interval where the mock reports the new image's rating while claiming to be processing — is never sampled, which is why the behaviour in this issue passes today.

That makes the fix cheap to verify: a test alongside test_rating_can_change which polls get_target_record between the update and wait_for_target_processed would answer the open question against real Vuforia and pin whichever answer it gives, without needing any new fixtures.