In T405839#11451405, @GrounderUK wrote:

Testing…

Looking good, thanks. Closing per request.

Testing…

In T411565#11429806, @Jdforrester-WMF wrote:

Yes, we've removed a great deal of the validation in the system for performance reasons, and this is one of those cases. We could adjust the built-in code to check this anyway (which obviates the point of a typed system, but oh well), but what's the worry about this behaviour?

Thanks. Yes, that’s fine with me!

Actually, some of those “passes” are “fails”; never trust an expected inequality!

I think this is T406848#11419629

In T359231#11423909, @gengh wrote:

[…snip…]

However, it's a tough UX decision.

[…]

• we can even include argument reference as a suggested type inside compositions (as I understand @GrounderUK is also suggesting)

(Just flagging that “Type:” should not be showing as “Z14K2” etc. Please see T358571#9603107. I think it would be preferable to show the programming language in place of “Z14K2”. Just saying….)

Although an emergency fix has been deployed with some success (thanks), we are still getting intermittent timeouts like this one.

Recurrence reported on Telegram at 09:12 UTC on 2025-11-30.

In T343564#11415281, @DSmit-WMF wrote:

Can we close this @Jdforrester-WMF ?

In T408136#11413980, @gengh wrote:

Thanks!
We show this notice message in converter pages (e.g. https://www.wikifunctions.org/wiki/Special:CreateObject?zid=Z46)

@GrounderUK Would it be useful to show it in normal code implementation ones, too?

In T409229#11413367, @DSmit-WMF wrote:

{F70688397}I just tried the use case in the 'try this function' on the python implementation and I see it working. Also in the javascript one.
(Also I don't see how this is tagged as front-end? @Jdforrester-WMF )

It appears that you may have used the “successful” reproduction steps given in “Other information” rather than those given in the “Steps to replicate…”. I can confirm that the quote object constructed by supplying a Reference continues to fail in the manner described. There should be no use of the “quoted reference” function when attempting to reproduce the error.

In T390226#11374219, @GrounderUK wrote:

Doesn’t that mean the variadic functions themselves would be agnostic on this question and just accept a Z8K1-list (or a list of Z17-lists, perhaps)?
[Not in this universe… Apologies for the confusion!]
Perhaps the nearest equivalent is that each ArgumentList is a [Z39, Z1] typed pair.

In T390226#11361085, @cmassaro wrote:

I feel a little queasy about a fallback mechanism that implicitly changes what gets put into the scope. Consider a case like this: let's say we have a function call

Apply( Z400, [ 'Z6', 'somestring' ] )

and Z400 points to some Z8, call it F.

Now let's say I call

Apply( F2, [ 'Z6', 'somestring' ] )

where F2 is a Z8 literal, functionally the same as F, except that its Z8K5 isn't a Z9 (this is allowed by the system).

The two function calls would generate Z7s like, respectively,

{ Z1K1: 'Z7', Z7K1: 'Z400', Z400K1: 'somestring' }

and

{ Z1K1: 'Z7', Z7K1: F2, K1: 'somestring' }

Now, let's say that Z400/F/F2 all contain an internal Z18 somewhere like

{ Z1K1: 'Z18', Z18K1: 'K1' }

In that case, the two ostensibly identical calls above would have different behavior, depending on the value of K1 that was (or was not) captured from some enclosing scope.

To be fair, this is a corner case, so I'm not strenuously against the idea.

Please note T406425

In T390226#11356227, @cmassaro wrote:

[…snip…]

I'm happy to put together a design document, but I want to give an opportunity here for people to express their preferences.

In T390226#11356969, @99of9 wrote:

I'm not sure if it's actually possible to do in the regular interface. I went into manual edit mode to copy what Denny/Al had done. But in any case, that level of difficulty is worth it for this kind of rare but enabling need.

I think it is possible using just the UI, which is how I did Z29349. When you choose to specify a function call’s Z7K1 other than by reference, the UI enables an “add argument” option for the object specifying the Z7K1 (the call to Z29350/Function identity, in this case).

Similar issue with (Integer, Rational number), quoted (Z29165): correct version of the code is used everywhere except when editing the test case.

Raised as T408638

In T406848#11260208, @cmassaro wrote:

When running from the deployment server, I got "Orchestration generally failed," while I did indeed get a timeout when running from the UI. Very weird.

I’m not sure about the specifics of this proposal, but I can certainly see opportunities that are currently blocked by default conversion. Custom conversion is generally avoidable but it would certainly be more convenient to be able to simply mark an implementation as requiring minimal conversion.

In T407207#11278518, @Jdforrester-WMF wrote:

"Taking too long" suggests a session failure/user-logged-out issue, which is (a) recoverable and (b) shouldn't happen very often at all. Let's fix this if that's the case. To investigate!

In T394664#11259555, @cmassaro wrote:

By "paramaterize functions ... by output type,"

Thanks, Cory. I promise not to lose any sleep over T322052 any time soon!

Similar issue with simplified Type object from Type (Z28945). I made a material change to its (then) single implementation (Z28947) to return a Quote object, timed at 19:58. When trying to add a test case the following morning, the actual result is not a Quote object:

In T404144#11280947, @gengh wrote:

@DVrandecic your composition looks fine to me!

I could successfully run it locally, so I made an edit to the test to update the revision ID and see if it was just an old failure lingering in the test results cache, and it appears this way.
Your implementation is working as expected.

Here's a relevant function call in the Api Sandbox

As noted above, T404144#11199042, the function call’s Z7K1 is a function call object rather than a reference. Happy for this not to be a problem 😎

Thank you, @gengh. I’ve fixed the problem you pointed out. I’ve also extended the “quick check” search at the top of “Wrongly configured function calls” to include that problem. It doesn’t find any similar cases.

Please see on-wiki question.

T396630 is still to do.

T396630

Successfully implemented

Fundamentally, the implementation assumes a shape for a Wikidata statement that is no longer valid (lacking a Z6003K7). I think the statements need to be filtered by property type (T382921 would be nice) and projected to their value to avoid locking in to a particular shape.

In T405991#11247620, @DMartin-WMF wrote:

… it places a greater burden on users …

In T394664#10889514, @cmassaro wrote:

[snip…] This failure mode will affect every type that wants to use type conversion, so it's important to address the root cause.

In T404725#11213569, @gengh wrote:

[snip]

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?

I don’t understand the delay on T382921. I don’t know the statistics, but I would expect labels and aliases in irrelevant languages would generally be bigger than external IDs, and the default omission of other languages would appear to be “common sense” to most users, I imagine. (Chicago has 224 labels, for example.)

@Jdforrester-WMF I’m not convinced that the problems are limited to the About box, although that’s a good place to start. Do you want a separate ticket for the unusual WikiLambda system update (deletion of labels), or does that have a simple explanation that eludes me?

I don’t know whether it warrants a different task, but I don’t see it as a
question of Wikifunctions visibility. The term used when adding or editing
an embedded function call is simply “Function” and the link to
Wikifunctions is labelled “Function from Wikifunctions”. I do not see the
expressions “Wikifunctions calls” or “calls to Wikifunctions” as being
anchored in that user experience. I suppose “Function is being called…”
gives some exposure to the “call” word (at least in English), but “Content
error” does not (and neither mentions Wikifunctions, of course).

No, it returns a Typed map (String, String) from Python and a Z547 from
JavaScript

We seem to have lost the “tenth argument breaks the UI” angle. I’ll raise a separate ticket related to problems editing Z23724 and https://www.wikifunctions.org/wiki/Z23723?uselang=en&diff=prev&oldid=220982, noting https://www.wikifunctions.org/wiki/Talk:Z23619?uselang=en#Bug

“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?

Also:

• Z28488

Just my opinion, but changing the function while creating a new test case doesn’t make sense in the user journey. That field should be fixed during creation. The current behaviour, where changing the function obliterates the function call and result validation without warning, is not helpful.

The function call in production is:

{
            "Z1K1": "Z7",
            "Z7K1": {
                "Z1K1": "Z7",
                "Z7K1": "Z14310",
                "Z14310K1": "Z28020",
                "Z14310K2": {
                    "Z1K1": "Z18",
                    "Z18K1": "Z28016K4"
                }
            },
            "K1": {
                "Z1K1": "Z18",
                "Z18K1": "Z28016K1"
            },
            "K2": {
                "Z1K1": "Z18",
                "Z18K1": "Z28016K2"
            },
            "K3": {
                "Z1K1": "Z18",
                "Z18K1": "Z28016K3"
            },
            "K4": {
                "Z1K1": "Z18",
                "Z18K1": "Z28016K4"
            }
        }

In T404897#11191162, @Jdforrester-WMF wrote:

[…snip…]
Hey, and users might want the reverse if e.g. a language is new and they want to find examples of how people have done something.

For that specific use case, Search is already a reasonable tool. But for the general case, yes.

In T403888#11192287, @DMartin-WMF wrote:

[…snip…]
Could you please confirm your observation, and if it's still true, let me know how to confirm it?

Yes. The key qualification (pun intended, sorry) is “…keys extracted from…”. By itself, the result from Z828 does indeed include the full list but extracting the Z2K2 key with Z803 or Z804 returns an evaluated Type object/representation, not the explicit Function call. The Z805 result also appears to represent a Type object rather than a Function call. Also, code implementations handed the full result from a call to Z828 actually receive an object containing a Type:

Some granularity would be useful. For example, there is an implementation with passing tests but it is disconnected. This would be useful even when everything is working normally.

[snip] …they might recognise "Wikifunctions" and go to the project chat for help/complaints.

Python evaluations are currently successful, thanks!

Noting passed tests for Python echo (Z15788) from “5 hours ago”, but implementation still times out and cases fail in edit mode.

Please also see T402079.

I’m seeing positive test results from “1 hour ago” but these now fail with Z575. See Z19846.

To me, it looks more like the first “calls to” would be the preferable omission.

In T395792#11165581, @99of9 wrote:

This seems like something the function writer and community should address.

I don’t see that working. If we’re not going to support nested functions, we’ll need to support format selection via the display functions, so that they are driven by language and/or specified format rather than just language.

Most of the embedded function calls have valid results in their previews, so my guess is that it’s the global cache (in error) that blocks the display of the (successful) preview result.

For the record, fetch Persistent object (Z828) should be able to do this. It can’t, because keys extracted from a Z828 result are themselves evaluated, so the Z2K2 becomes a Type rather than a Function call. (This is understandable but not sensible, but that’s for another ticket.)

All good ideas, to which I would add T383326.

Thanks for the fix!

In T402079#11134804, @99of9 wrote:

I didn't think there was such a mechanism. It would help if someone who knows could tell us.

In T402079#11130353, @99of9 wrote:

In T402079#11129136, @GrounderUK wrote:

…Two compositions have been left with failures continuing (latest at around 2025-08-28 14:58 UTC)…

Also observe issues with Z11410. For an unidentified reason, all implementations were observed to fail with a Z503 (including discard from start of first substring, JavaScript (Z14700), in JavaScript). Two compositions have been left with failures continuing (latest at around 2025-08-28 14:58 UTC) but tests passing in edit mode. “Nudged” implementations have been succeeding since before 06:52 UTC.

We had a problem with the display function for Day of the week Z24041. Fixing this appears not to correct “content errors” on a page with an embedded function relying on this display function. The function now returns the correct value in preview but not after the change is applied.

This now appears to have been fixed, thanks (and December now has 15 labels, a 200% improvement in a little over a year).

Possibly related:

In T402079#11091500, @99of9 wrote:

Oh, hmm. @GrounderUK just nudged the composition and they're all working again. But something is wonky somewhere.

• do we need to be more selective about which parts of WD entities we retrieve?

I think we should do some of T373735 at the same time (or first), because Recent changes and List all objects of a given type (etc) are contexts where we see Implementation and Test case labels without their function’s context.

Perhaps we should include this with T373735?

I’m inclined to consider this problem beautifully resolved. Am I missing something?

The tests now all seem to be passing correctly.

Ah, that’s excellent news, thank you!

In T395464#10870868, @cmassaro wrote:

[…snip…]

Edit: I see no evidence that Z18475 is getting called. Can you wire the functions back up so I can reproduce what you're seeing?