I’ve disconnected the “preferred” JavaScript implementation (Z14403) for now.

This follows on from my Telegram comment:
“I don’t know about over-strict… I don’t think the elements match, in Python terms or otherwise, because the Z11K1s in the expected results contain ZReferences whereas the Wikidata ones contain Z60 objects. This seems to be a v2 change. Note that Z12879 has passing tests from “6 months ago” and now fails with

Error type: Unspecified error
Error data:
error information: "cannot read property 'Z1K1' of undefined"

I’ve added Z32039 to get the function working again, which will purge the old test results for the JavaScript implementation when I connect it (I expect).”

The selection from the configuration now seems to be working, but we get “not a month” errors further down. This might be from one of the converters or something else in this list. (Tip: put the ZID in the error text, or as an additional context string when using Wikifunctions.Error.)

I think the culprit is Z20343 (month from day of the Roman year), which seems to return a calendar month, nested in a calendar month, nested in a calendar month. I presume the triple nesting causes errors downstream. Look at this link: https://www.wikifunctions.org/view/en/Z20343?call=%7B%22Z1K1%22%3A%22Z7%22%2C%22Z7K1%22%3A%22Z20343%22%2C%22Z20343K1%22%3A%7B%22Z1K1%22%3A%22Z20342%22%2C%22Z20342K1%22%3A%7B%22Z1K1%22%3A%22Z16098%22%2C%22Z16098K1%22%3A%7B%22Z1K1%22%3A%22Z16098%22%2C%22Z16098K1%22%3A%22Z16101%22%7D%7D%2C%22Z20342K2%22%3A%7B%22Z1K1%22%3A%22Z13518%22%2C%22Z13518K1%22%3A%2215%22%7D%7D%7D

In T419789#11717526, @ChaoticVermillion wrote:

I think the culprit is Z20343 (month from day of the Roman year), which seems to return a calendar month, nested in a calendar month, nested in a calendar month. I presume the triple nesting causes errors downstream. Look at this link: https://www.wikifunctions.org/view/en/Z20343?call=%7B%22Z1K1%22%3A%22Z7%22%2C%22Z7K1%22%3A%22Z20343%22%2C%22Z20343K1%22%3A%7B%22Z1K1%22%3A%22Z20342%22%2C%22Z20342K1%22%3A%7B%22Z1K1%22%3A%22Z16098%22%2C%22Z16098K1%22%3A%7B%22Z1K1%22%3A%22Z16098%22%2C%22Z16098K1%22%3A%22Z16101%22%7D%7D%2C%22Z20342K2%22%3A%7B%22Z1K1%22%3A%22Z13518%22%2C%22Z13518K1%22%3A%2215%22%7D%7D%7D

Thanks. If so, this is closely related to T419915

Useful test case: {"Z1K1":"Z7","Z7K1":{"Z1K1":"Z8","Z8K1":["Z17",{"Z1K1":"Z17","Z17K1":"Z20342","Z17K2":"Z22941K1","Z17K3":{"Z1K1":"Z12","Z12K1":["Z11",{"Z1K1":"Z11","Z11K1":"Z1002","Z11K2":"calendar day"}]}},{"Z1K1":"Z17","Z17K1":"Z60","Z17K2":"Z22941K2","Z17K3":{"Z1K1":"Z12","Z12K1":["Z11",{"Z1K1":"Z11","Z11K1":"Z1002","Z11K2":"language to display in"}]}}],"Z8K2":"Z6","Z8K3":["Z20","Z22942","Z22944","Z24977","Z24978","Z26120","Z26138","Z26253","Z28490"],"Z8K4":["Z14",{"Z1K1":"Z14","Z14K1":"Z22941","Z14K2":{"Z1K1":"Z7","Z7K1":"Z13036","Z13036K1":{"Z1K1":"Z7","Z7K1":"Z14310","Z14310K1":"Z22940","Z14310K2":{"Z1K1":"Z18","Z18K1":"Z22941K2"}},"Z13036K2":{"Z1K1":"Z18","Z18K1":"Z22941K1"}}}],"Z8K5":"Z22941"},"Z22941K1":{"Z1K1":"Z20342","Z20342K1":{"Z1K1":"Z16098","Z16098K1":"Z16102"},"Z20342K2":{"Z1K1":"Z13518","Z13518K1":"1"}},"Z22941K2":"Z1002"}

apine opened https://gitlab.wikimedia.org/repos/abstract-wiki/wikifunctions/function-orchestrator/-/merge_requests/603

Avoid expanding identity keys in composition language v2.

Change #1259205 had a related patch set uploaded (by Jforrester; author: Jforrester):

[operations/deployment-charts@master] wikifunctions: Upgrade orchestrator from 2026-03-18-023444 to 2026-03-23-124102

https://gerrit.wikimedia.org/r/1259205

Change #1259205 merged by jenkins-bot:

[operations/deployment-charts@master] wikifunctions: Upgrade orchestrator from 2026-03-18-023444 to 2026-03-23-124102

https://gerrit.wikimedia.org/r/1259205

Temporary fix, as before: disconnected Z14403.

Tests were passing with results from nine days ago but now fail. This is because the default function was being selected in all cases, owing to a failure to match language tags, because languages in Z14293K2 are being passed to JavaScript as references, with no tag.

Composition Z14349 is now preferred, but this is ultimately recursive in Z14351, with increased performance degradation as configurations expand.

To quote from `T421322

It seems to me that integration testing should have identified that most AW content would start breaking. For both performance and resilience, we should urgently consider the site’s critical dependency on Z14310 and Z13318 and (probably) replace the combination with a built-in, possibly folding in a more efficient equivalent of Z14294, which does not scale well.

[comment from above, for context]

In T419789#11706360, @GrounderUK wrote:

I’ve disconnected the “preferred” JavaScript implementation (Z14403) for now.

This follows on from my Telegram comment:
“I don’t know about over-strict… I don’t think the elements match, in Python terms or otherwise, because the Z11K1s in the expected results contain ZReferences whereas the Wikidata ones contain Z60 objects. This seems to be a v2 change. Note that Z12879 has passing tests from “6 months ago” and now fails with

Error type: Unspecified error
Error data:
error information: "cannot read property 'Z1K1' of undefined"

I’ve added Z32039 to get the function working again, which will purge the old test results for the JavaScript implementation when I connect it (I expect).”

The selection from the configuration now seems to be working, but we get “not a month” errors further down. This might be from one of the converters or something else in this list. (Tip: put the ZID in the error text, or as an additional context string when using Wikifunctions.Error.)

OK, so looking at Z14356, before this was relying on the response being an unresolved Z9 to Z14295, but we're now resolving Z9s to Functions to solve a different issue.

Re-writing (replacing) the Function so its Implementations don't use References for items they don't ever want resolving, but instead wrapping them in Z99/Quotes, is probably the best way forward.

Maybe that too… but when the default function is returned, it seems not to be a problem. The problem is that, for example, a ZReference for Z1002 does not have a language tag == "en", so the code can never return anything other than the default (whether as function, reference, or quoted reference).

With this hardcoded hack in Z14403, the three English tests pass (and the default case fails):

function Z14310( Z14310K1, Z14310K2 ) {
const lang = Z14310K2.Z60K1;
const configs = Z14310K1.Z14294K1;
for (const config of configs) {

		const langlist = config.Z14293K2;
		for (const option_lang of langlist) {
			if ( option_lang.Z9K1 == 'Z1002' ) {
				return config.Z14293K1; //corresponding fucnction
			}
		}

}
return Z14310K1.Z14294K2; //default function
}

(The language received by the function is already a resolved object with no identity, so we can’t compare by Z60 reference either.)

In T419789#11782320, @Jdforrester-WMF wrote:

OK, so looking at Z14356, before this was relying on the response being an unresolved Z9 to Z14295, but we're now resolving Z9s to Functions to solve a different issue.

Re-writing (replacing) the Function so its Implementations don't use References for items they don't ever want resolving, but instead wrapping them in Z99/Quotes, is probably the best way forward.

dmartin opened https://gitlab.wikimedia.org/repos/abstract-wiki/wikifunctions/function-orchestrator/-/merge_requests/644

Draft: Call fullyRealize instead of realizeTopLevel in fullyRealizedArgument

Thanks, @GrounderUK and all for the detailed info. As noted in the last comment above, The central problem is that the JavaScript implementation stopped working, and that's because the Z60/language objects inside of the language configuration instance are no longer resolved; in other words, they come through to JavaScript as references rather than literals.

There is a one-line change that apparently fixes this, in MR 644 mentioned above; all the tests work again for that implementation in my local dev env. The other 2 implementations are still working, and all the unit tests are passing.

I'm going to check in with the team to make sure this simple change doesn't cause any other problems, and consider whether this is the best way to go.

Update: we decided to go ahead with this simple change, and expect it to be deployed next Wednesday, April 29.

In general, V1 orchestrator code resolved references before sending them to code implementations. Currently V2 code doesn't do that, but with this one-line change, it will do that again. We understand that this particular behavior of current V2 (not resolving references) was deployed too abruptly, and apologize for that. In general, however, going forward the Orchestrator cannot guarantee that references will always be resolved, and implementations need to be prepared to handle both forms, references and literals. We will communicate more about this in upcoming community conversations.

dmartin closed https://gitlab.wikimedia.org/repos/abstract-wiki/wikifunctions/function-orchestrator/-/merge_requests/644

Draft: Call fullyRealize instead of realizeTopLevel in fullyRealizedArgument

The simple change I mentioned above was in fact deployed today, but not as MR 644. it was deployed as a reversion: MR 646. Also, @GrounderUK has reconnected Z14403.

Z14403 has been reconnected with all tests passing and all the tests of https://www.wikifunctions.org/view/en/Z22941 are passing (but one disconnected one). Given that, @99of9 , do you agree this can be closed?

(Failing tests of Z22941 was the original concern of this ticket.)

@DMartin-WMF This comment is just a test; please ignore.

@DMartin-WMF This comment is also just a test; please ignore.