Page MenuHomePhabricator

Unexpected "wrong content type" error when running test case despite identical expected and actual outputs
Closed, ResolvedPublicBUG 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 'Q9610'") 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.

Putting Z1 into Z10012 works and outputs 1Z, as exemplified by this test, https://www.wikifunctions.org/view/en/Z16826

P1 -> 1P also doesn't work, see https://www.wikifunctions.org/view/en/Z18328
P1 -> 1P also doesn't work, see https://www.wikifunctions.org/view/en/Z18329

so summing up:

  • L1, Q1, P1 does not work
  • Z1 does work
  • -L1, -Q1, -P1 does work (prefixing the id with a dash works)

This fails for all capital letters followed by a number (C4, T2, O4, etc.). However it works for Z and also K: https://www.wikifunctions.org/view/en/Z18330

I believe this is due to a mismatch in how different parts of the system treat these strings. Some parts of the system treat any capital letter followed by digits (/[A-Z][1-9][0-9]*/) as Z9/Reference and any other string as Z6/String; other parts of the system are stricter, and only treat strings matching /[QZ][1-9][0-9]*/ (or possibly only /Z[1-9][0-9]*/) as Z9/References. None of these regexes is correct: it should be /[A-JL-Z][1-9][0-9]*/, since things like K1 can't ever be Z9/References.

The general problem exemplified by Z10012 appears to have been fixed now, so I have connected the test cases. The specific issue related to Z10043 persists, although the error now appears to be Z518/Object type mismatch (I don’t know whether that is a recent change).

this can be closed now. not reproducible after the implementation of wikibase types

DMartin-WMF claimed this task.
DMartin-WMF subscribed.

Thanks greatly to everyone who created, tested, and/or provided info on this ticket! Closing.