Page MenuHomePhabricator

Evaluations returning Void are flagged as invalid results in the details even when Void is the expected and correct result
Open, LowPublicBUG REPORT

Description

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

What happens?:
The Errors concertina reports “Invalid evaluation result” (Z560).

What should have happened instead?:
No error (because Void is the correct result)

Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia):

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

The same result can be observed by echoing Void, for example.

I can see an argument for leaving things as they are for the time being, but the intentional use of Void in Wikidata fetch functions invites a re-think.

Leaving as a Bug report for now because non-errors should not be reported as errors, but feel free to change.

Event Timeline

Jdforrester-WMF renamed this task from Evaluations returning Void are flagged as invalid results even when Void is the expected and correct result to Evaluations returning Void are flagged as invalid results in the details even when Void is the expected and correct result.Sep 17 2025, 3:51 PM
Jdforrester-WMF triaged this task as Low priority.

@GrounderUK @Jdforrester-WMF What's the meaning of "flagged as invalid results"?
The way I see this:
✅ The test is correctly marked as passing (green), because it passes (void === void)
✅ The metadata shows the errors received while evaluating the first call, which happen, and are expected.

What's the expected outcome of this task?

  1. should the errors be hidden? I am not very convinced about this, because obfuscating real metadata returned by the orchestrator might make test case modeling much more complex.
  2. should the errors returned by the orchestrator be presented or titled differently? this seems reasonable, but I'd love to hear some suggestions. What would be useful here?

“Flagged as invalid” means a Z560 was returned and interpreted as an “invalid execution result”. We don’t understand why this is “expected” from a valid call that evaluates correctly. What is the error and how can we avoid it?

[snip]

  1. should the errors returned by the orchestrator be presented or titled differently? this seems reasonable, but I'd love to hear some suggestions. What would be useful here?

It would be useful to know what error the orchestrator thinks it has encountered. My premise is simply that, conceptually, there is no error here, so we don’t want to mislead people into thinking there is a problem that needs to be fixed. Because of T373607, we are not yet able to rely on a green tick.

Adding example function calls (because we can, thanks). Correctly echoing is no kind of error.

Pasting the result here for clarity:

{
  "Z1K1": {
    "Z1K1": "Z7",
    "Z7K1": "Z882",
    "Z882K1": "Z6",
    "Z882K2": "Z1"
  },
  "K1": "errors",
  "K2": {
    "Z1K1": "Z5",
    "Z5K1": "Z560",
    "Z5K2": {
      "Z1K1": {
        "Z1K1": "Z7",
        "Z7K1": "Z885",
        "Z885K1": "Z560"
      },
      "Z560K1": {
        "Z1K1": "Z99",
        "Z99K1": {
          "Z1K1": {
            "Z1K1": "Z9",
            "Z9K1": "Z22"
          },
          "Z22K1": {
            "Z1K1": {
              "Z1K1": "Z9",
              "Z9K1": "Z21"
            }
          }
        }
      }
    }
  }

Thanks. We don’t get to see the detail, but we do get a well-formed Unit, as far as I can tell.