Skip to content

Work list for once the Model Target credentials are rotated #3444

Description

@adamtheturtle

Follow-up to #3441, which tracks the rotation itself, and the first instance of #3445, which covers the general class: mock behaviour which has never been observed from real Vuforia and is indistinguishable from behaviour which has. This issue is the work list for after the Model Target Web API credentials in secrets.tar.gpg return a token again, so that the rotation is not the point at which someone has to reconstruct what it unblocks.

Nothing here is actionable until #3441 is done. Rechecked today: the archive still gives 401 {"error":"invalid_client"}, secrets.tar.gpg on main has not changed since #3366, and the only Vuforia GitHub secret is PASSPHRASE_FOR_VUFORIA_SECRETS in the vuforia environment — a passphrase, not the credentials. GitHub Actions secret values cannot be read back, so no amount of updating secrets on GitHub delivers new credentials; only a re-encrypted, committed archive does.

1. Confirm the assumptions the mock currently makes

Each of these is behaviour the mock asserts today which has never been seen from real Vuforia. Each needs one probe, then either a confirmation or a correction to the mock.

  • A dataset creation body which is valid JSON but not a JSON object. The mock reports every required top-level field as missing (/models, /name, /targetSdk). Assumed in A JSON body which is not an object raises an uncaught AttributeError #3391.
  • A dataset creation body which is not valid UTF-8. The mock reports it as invalid JSON, in the same shape as a malformed JSON body: 400 / ERROR / Invalid Json: .... Assumed in Reject Model Target request bodies which are not valid UTF-8 #3440.
  • An OAuth2 token request whose form body is not valid UTF-8. The mock decodes it leniently, so it is treated as a request which does not name a grant type and succeeds. Assumed in Reject Model Target request bodies which are not valid UTF-8 #3440; currently TestMockOnlyErrors::test_oauth2_token_body_not_utf_8.
  • The training status which a download request reports for a dataset whose generation failed. The mock says failed != done; the only status observed from real Vuforia is not-started, for a dataset requested just after creation. Added in Report the failed training status for failed Model Target downloads #3443; currently TestMockOnlyErrors::test_failed_dataset_cannot_be_downloaded.
  • A request with no Content-Type, and one with an empty Content-Type, on each dataset route. Currently covered by TestInvalidJson::test_wrong_content_type against the mock only.
  • Every error.expected.jsstring, error.expected.validenum and element is required detail string asserted by TestErrorResponses::test_invalid_dataset_request. These are the largest block of unverified assertions — 33 parametrisations which currently only assert that the mock agrees with itself.

2. Convert mock-only tests which the credentials unblock

Move out of TestMockOnlyErrors into a verified fake class, correcting the mock wherever the observed response differs:

  • test_oauth2_token_body_not_utf_8
  • test_unknown_dataset already runs against real Vuforia; check the userId: target format still matches after rotation, since the numeric portion is per-account and the new client may sit on a different account.

These stay mock-only even after rotation, unless the new credentials also carry the advanced and State-Based scopes (#3202):

  • test_advanced_model_count_exceeds_limit
  • test_advanced_realistic_appearance_not_in_enum
  • test_dataset_is_not_visible_to_the_other_dataset_type
  • test_state_based_dataset and test_invalid_state_based_dataset

And these stay mock-only regardless, because they need a dataset generated on every run or a failure provoked on demand:

  • test_processing_dataset_cannot_be_downloaded
  • test_failed_dataset_cannot_be_downloaded (though the status name it asserts should be confirmed — see section 1)

3. Close out the issues which are waiting on observation

4. Update docs/source/differences-to-vws.rst

The Model Target section carries several sentences whose only purpose is to record that something was unverified. Each should be deleted once confirmed, or rewritten to describe a real difference once corrected:

  • "An OAuth2 token request body which cannot be decoded as UTF-8 is treated as one which does not name a grant type; the real response to such a body has not been observed." — delete the clause after the semicolon, or correct the behaviour.
  • "The name which real Vuforia reports for a failed dataset has not been observed."
  • "Dataset creation request bodies which are valid JSON but not JSON objects are reported as missing every required top-level field."
  • "Dataset creation request bodies which cannot be decoded as UTF-8 are reported as invalid JSON, as malformed JSON bodies are."
  • "For unknown Model Target datasets, the mock returns an error whose target is userId:mock." — keep, but confirm the real format is still userId:<numeric> on the new account.
  • "The generated dataset download is a small valid zip file containing request metadata, not a real Vuforia Engine Model Target dataset." — narrow to describe the remaining difference once Make Model Target dataset downloads more realistic #3195 is done.
  • The mock-only paragraph at the end of the section lists reasons which will no longer apply. Remove each entry as its test is converted, and make sure the remaining ones say why they are still mock-only (missing scope vs. cannot be provoked on demand) rather than just that they are.

5. Remove the failure mechanism

Definition of done

The real-Vuforia parametrisations of tests/mock_vws/test_model_target_web_api.py report 0 xfailed, every sentence in differences-to-vws.rst describes a difference which is real rather than one which is unobserved, and each remaining mock-only test says which of the two reasons applies to it.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions