Skip to content

Verify that an update does not reset the tracking rating to -1 - #3549

Merged
adamtheturtle merged 1 commit into
mainfrom
adamtheturtle/next-issue-no-open-pr
Sep 6, 2026
Merged

Verify that an update does not reset the tracking rating to -1#3549
adamtheturtle merged 1 commit into
mainfrom
adamtheturtle/next-issue-no-open-pr

Conversation

@adamtheturtle

@adamtheturtle adamtheturtle commented Sep 6, 2026

Copy link
Copy Markdown
Member

ImageTarget.status measures processing from last_modified_date while tracking_rating measures its -1 window from upload_date, so the -1 window never recurs after an update; #3398 argued that the real Vuforia could not behave that way, since computing the rating is what processing is for.

Probing the real Vuforia with a throwaway database says otherwise, over three image updates in both quality directions and two name-only updates: the -1 window is real but upload-only, lasting about one second of a roughly thirty second processing time, and an update returns a target to processing and publishes the new image's rating straight away without passing through -1 again.

The mock's behaviour was therefore already right and the two anchors are right to differ, so this changes no behaviour: it records the observation where the -1 window is implemented and in differences-to-vws.rst and contributing.rst, and adds TestImage::test_rating_does_not_return_to_minus_one (with its ci_pattern entry) to pin it.

That test runs against the real Vuforia as well as the mocks, which is what makes it worth having — it asserts the rating is in range(6) immediately after an update, which holds whether the old or the new rating has propagated, and it passes against the real Vuforia.

Closes #3398.

🤖 Generated with Claude Code

@adamtheturtle @claude
Verify that an update does not reset the tracking rating to -1
2fc1691 
`ImageTarget.status` measures processing from `last_modified_date` and
`tracking_rating` measures its -1 window from `upload_date`, so after an
update the two disagree about when processing started and the -1 window
never recurs. #3398 argued that the real Vuforia could not behave that
way, because computing the rating is what processing is for.

Probing the real Vuforia with a throwaway database says otherwise, over
three updates in both quality directions and two name-only updates:

    after ADD (high quality)
      t= 0.5s  processing  rating=-1
      t= 1.1s  processing  rating=5
      t=27.6s  success     rating=5
    after UPDATE (to a low rating image)
      t= 0.4s  processing  rating=0
      t=34.4s  success     rating=0
    after UPDATE (name only)
      t= 0.4s  processing  rating=0
      t= 2.2s  success     rating=0

The -1 window is real but upload-only, and it is about one second of a
roughly thirty second processing time rather than the mock's half. An
update returns a target to 'processing' and publishes the new image's
rating straight away, without passing through -1 again. The old rating
was sometimes visible for under a second first, in two of the three
image updates, which looks like read-path lag rather than a window.

So the mock's behaviour was already right, and the two anchors are
right to differ. Rather than change it, record the observation where
the -1 window is implemented and in the docs, and add a test which
pins it. The test runs against the real Vuforia as well as the mocks,
which is what makes it worth having: it asserts the rating is in
range(6) immediately after an update, which holds whether the old or
the new rating has propagated.

Closes #3398.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

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

1 participant

@adamtheturtle