VuMark instance_id is validated for truthiness rather than type

[adamtheturtle]

What happens

The VuMark instance generation endpoint checks instance_id for truthiness and nothing else:

    request_json = json.loads(s=request.body)
    instance_id = request_json.get("instance_id", "")
    if not instance_id:
        raise InvalidInstanceIdError

src/mock_vws/_requests_mock_server/mock_web_services_api.py:600, and the same three lines in src/mock_vws/_flask_server/vws.py:679.

So the accept/reject split follows Python truthiness rather than any rule about instance IDs:

instance_id="abc"      -> 200
instance_id=""         -> 422
instance_id=5          -> 200
instance_id=0          -> 422
instance_id=0.0        -> 422
instance_id=1.5        -> 200
instance_id=true       -> 200
instance_id=false      -> 422
instance_id=[1]        -> 200
instance_id=[]         -> 422
instance_id={"a": 1}   -> 200
instance_id={}         -> 422
instance_id=null       -> 422

A JSON array or object as the instance ID produces a successful VuMark image.

Why it matters

The two directions are wrong for different reasons, and only one of them is clear-cut.

[1] and {"a": 1} returning 200 cannot be right under any reading. Whatever an instance ID is, it is not a JSON object.

0 and false returning 422 is the more interesting one. VuMark templates declare an instance ID data type, and a numeric template makes 0 a plausible legitimate value which the mock currently rejects. So this is not simply "add an isinstance(instance_id, str) check" — that would harden the array case and cement the numeric-zero case, and the second might be a false rejection.

Every other typed field in the VWS mock has a dedicated validator — validate_name_type, validate_metadata_type, validate_active_flag, validate_width — each with its own module under _services_validators. instance_id is the exception: it is checked inline in the handler, in both backends, which is likely why it never got one.

Why it was not caught

tests/mock_vws/test_vumark_generation_api.py types its helper as instance_id: str, so every test sends a string. test_empty_instance_id covers "". No test sends a non-string value, so the whole table above is untested behaviour.

Suggested resolution

This wants verification before a fix, more than most of these. The questions for a real database are what happens for a JSON number, a boolean, an array, an object, and specifically for 0 against a numeric-typed VuMark template.

Once that is known, the check belongs in a validator module alongside the other type validators rather than inline in two handlers — which also stops the two backends drifting on it, as they would have to change together.

If verification turns out to be impractical, rejecting arrays and objects while leaving numbers accepted would be a strict improvement on truthiness, and the remaining uncertainty about 0 could go in docs/source/differences-to-vws.rst, which already has a VuMark section noting that the instance ID is not encoded into the returned image.