I see. There are a few things going on here.

Hmm. I think the problem here is the use of Z17464, which is defined for references. The fully-resolved types that are returned are Z4/Types, not Z9/References. It seems to be that there should be a Type equality function for this case. Am I missing something?

New Numbers:

We do have other means of measuring this more granular time spans, but we don't expose them in the UI. It would be useful to exclude wait times when determining the fastest implementation.

We won't see them yet, no. Conceptually, there are three different interesting time spans in the evaluator:

Thanks to @DMartin-WMF for the numbers:

The above MR demonstrates that the evaluator can handle these escape sequences, and that they are interpreted correctly when injected into code with eval/exec (if they were not interpreted correctly, the regex matches would not have been correct).

@Harej : Just to be clear that it's the same issue, what happens if you double-escape all the Unicode sequences (e.g., \\u200e)?

I also see that this works if you double-escape, so the regex can be r'\\d'. This is still not great, but it should work for now.

I've tracked this down to includes/ZObjectContent.php. It is true that the \d escape sequence is illegal inside a JSON string, so FormatJson rightly complains about it.

Hm. So, I have been able to repro. The \ds are the culprit.

I would be happy to continue this discussion in some venue in order to determine what the need is; if that venue is here, I'm fine with this task remaining open. To be clear, though, this isn't a bug: the system is working as intended.

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.

I'd like to add a little more context here.

Looking back at this, I don't think this is the right place to catch degenerate objects. Let's close as Rejected.

We have this weird corner case in the backend. {Z1K1: 'Z9', Z9K1: 'Z41'} should be treated as a Boolean, but if often is not; often, what the backend expects is

Close as duplicate of T365515?

This seems to be working now!

This test doesn't handle the Z18 case, but our scoping rules make that kind of hard :-/

I recommend closing as declined; this isn't necessary.

I think this is now fixed. We audited these during the big orchestrator test refactor.

In T368320#10015662, @gengh wrote:

It seems to me that in this case (showing the implementation composition), the string renderer shouldn't even come into play, unless the values are complete (there are no argument references).
Should we stop such cases from collapsing into the string renderer component and just stop that function call from running altogether?

Alternatively: we might consider having parser/renderer functions operate over Z99s. Then the parser/renderer functions themselves can handle Z7, Z9, and/or Z18 literals however they want, since these "nonterminal" types will be represented faithfully inside the Z99.

Thanks @gengh for pointing me to the call being sent to the orchestrator.

This is now passing on both of the linked tests. The error in the task description points to an executor error, and the empty string after it means that the executor just didn't return anything. Could have been something ephemeral like resource exhaustion or a timeout. Marking as "needs sign-off" for now.