Page MenuHomePhabricator

Unexpected "wrong content type" error when running test case despite identical expected and actual outputs
Open, MediumPublicBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

  • Visit https://www.wikifunctions.org/wiki/Z10041
  • Go to the list of test cases in the "Details" tab
  • View the details ("ⓘ") of Z10043 ("language of L301993 at revision 1202251564 is 'x'") using Z10042 ("(!) get lexical category from Lexeme JSON (Python)")

What happens?:

The test fails with Validator Error Summary "[Z539/wrong content type]", despite the "Expected Result" and the "Actual Result" being identical.

What should have happened instead?:

The test passes because the "Expected Result" and the "Actual Result" are identical.

Other information (browser name/version, screenshots, etc.):

For comparison, https://www.wikifunctions.org/wiki/Z10222 has this same problem, but https://www.wikifunctions.org/wiki/Z10037 does not have this problem.

Event Timeline

The raw string Q9610 is not safe as a Z6/String, it's interpreted as a Z9/reference to a Wikidata item (which is a known general type, but no specific Wikidata one yet). You want to respond with a wrapper in this case (or wait for the Z9 type to be supported).

So, this will affect any string function any time someone types in a QID as the input? I just tried entering "Q1" into https://www.wikifunctions.org/view/en/Z10012, and this seems to be the case. I guess I don't fully understand why it is "unsafe", but can't the software interpret it as a string if it's in a string variable field, but not if it's in a Z9 type field?

PS I've also made a note at https://www.wikifunctions.org/w/index.php?title=Talk%3AZ539#Qids_are_a_protected_data_type so that people who get that error message may come here to find out more information.

Thanks, the example on Z10012 with Q1 is indeed simpler and exemplifies this better.

This shouldn't happen. We really encode this as a string when we send this to the backend. This behavior is bad - especially when it is explicitly marked as a String.

When one sends a 1Q to Z10012, it all works fine, so the problem is happening only on the input side it seems.