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

WFFunction: Validate Z8K1 is a list before iterating declarations

ecarg merged https://gitlab.wikimedia.org/repos/abstract-wiki/wikifunctions/function-orchestrator/-/merge_requests/633

WFFunction: Validate Z8K1 is a list before iterating declarations

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

[operations/deployment-charts@master] wikifunctions: Upgrade orchestrator from 2026-03-31-162258 to 2026-04-07-234729

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

Change #1268967 merged by jenkins-bot:

[operations/deployment-charts@master] wikifunctions: Upgrade orchestrator from 2026-03-31-162258 to 2026-04-07-234729

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

A patch that hopefully fixes this has been deployed.

Hey @Jdforrester-WMF
Nope
The UI gives me the next error (in red background)

Wikifunctions returned a failed response: Unspecified error

And the undelying API call:

"Z500K1": "cannot read property 'Symbol.iterator' of undefined"

It looks like the crash might be in Z22979: Z6001K5 is undefined when the input lacks statements. Adding if ( !claims ) { return result; } after line 3 should fix it.

In T422052#11840600, @HakanIST wrote:

It looks like the crash might be in Z22979: Z6001K5 is undefined when the input lacks statements. Adding if ( !claims ) { return result; } after line 3 should fix it.

The for (const claim of claims ) {…} loop would already be a no-op, though, so this shouldn't change the response? But either way, our server code shouldn't treat this as a fatal in our code. :-)

In T422052#11799968, @DSantamaria wrote:

Hey @Jdforrester-WMF
Nope
The UI gives me the next error (in red background)

Wikifunctions returned a failed response: Unspecified error

And the undelying API call:

"Z500K1": "cannot read property 'Symbol.iterator' of undefined"

When I try to run this directly I get a different result: https://www.wikifunctions.org/wiki/Z27868?call=%7B%22Z1K1%22%3A%22Z7%22%2C%22Z7K1%22%3A%22Z27868%22%2C%22Z27868K1%22%3A%7B%22Z1K1%22%3A%22Z7%22%2C%22Z7K1%22%3A%22Z21449%22%2C%22Z21449K1%22%3A%7B%22Z1K1%22%3A%22Z6092%22%2C%22Z6092K1%22%3A%22P575%22%7D%2C%22Z21449K2%22%3A%7B%22Z1K1%22%3A%22Z7%22%2C%22Z7K1%22%3A%22Z21449%22%2C%22Z21449K1%22%3A%7B%22Z1K1%22%3A%22Z6092%22%2C%22Z6092K1%22%3A%22P61%22%7D%2C%22Z21449K2%22%3A%7B%22Z1K1%22%3A%22Z7%22%2C%22Z7K1%22%3A%22Z6821%22%2C%22Z6821K1%22%3A%7B%22Z1K1%22%3A%22Z18%22%2C%22Z18K1%22%3A%22Q1838%22%7D%7D%7D%7D%7D

Is it possible this is just caching?

@Jdforrester-WMF, I have run into this error trying to run several other functions. Please see https://www.wikifunctions.org/view/en/Z34050?call=%7B%22Z1K1%22%3A%22Z7%22%2C%22Z7K1%22%3A%22Z34050%22%2C%22Z34050K1%22%3A%7B%22Z1K1%22%3A%22Z6095%22%2C%22Z6095K1%22%3A%22L1453682%22%7D%2C%22Z34050K2%22%3A%22Z1002%22%2C%22Z34050K3%22%3A%22Z1861%22%2C%22Z34050K4%22%3A%7B%22Z1K1%22%3A%22Z6091%22%2C%22Z6091K1%22%3A%22Q14549%22%7D%7D.

In T422052#11955545, @Jdforrester-WMF wrote:

The for (const claim of claims ) {…} loop would already be a no-op, though, so this shouldn't change the response? But either way, our server code shouldn't treat this as a fatal in our code. :-)

I think the root issue is in WFBuiltinImpl.evaluate() in WFImplementation.js. This method does not catch native JS errors from builtin functors, so a TypeError escapes up and becomes a generic Z507. The fix in MR633 guards only Z8K1, but the same pattern exists in many other builtins, which might explain why @Redmin sees it in Z34050 too.

Catching non-WFException errors at that single point would protect all builtins at once. I was able to reproduce the bug locally and this approach seems to work.

In T422052#11955909, @Redmin wrote:

@Jdforrester-WMF, I have run into this error trying to run several other functions. Please see https://www.wikifunctions.org/view/en/Z34050?call=%7B%22Z1K1%22%3A%22Z7%22%2C%22Z7K1%22%3A%22Z34050%22%2C%22Z34050K1%22%3A%7B%22Z1K1%22%3A%22Z6095%22%2C%22Z6095K1%22%3A%22L1453682%22%7D%2C%22Z34050K2%22%3A%22Z1002%22%2C%22Z34050K3%22%3A%22Z1861%22%2C%22Z34050K4%22%3A%7B%22Z1K1%22%3A%22Z6091%22%2C%22Z6091K1%22%3A%22Q14549%22%7D%7D.

Thanks! That reproduction step is helpful.

In T422052#11956417, @HakanIST wrote:

In T422052#11955545, @Jdforrester-WMF wrote:

The for (const claim of claims ) {…} loop would already be a no-op, though, so this shouldn't change the response? But either way, our server code shouldn't treat this as a fatal in our code. :-)

I think the root issue is in WFBuiltinImpl.evaluate() in WFImplementation.js. This method does not catch native JS errors from builtin functors, so a TypeError escapes up and becomes a generic Z507. The fix in MR633 guards only Z8K1, but the same pattern exists in many other builtins, which might explain why @Redmin sees it in Z34050 too.

Catching non-WFException errors at that single point would protect all builtins at once. I was able to reproduce the bug locally and this approach seems to work.

Yeah, unfortunately I think you're right; we're going to have to catch all these errors blindly and re-throw as Z507s, and rely on warning us in the logs so the devs come and fix the issues in the built-ins one-by-one. I'll do this now.

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

WFFunction.callWith(): Wrap raw implementation errors as Z507

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

WFFunction.callWith(): Wrap raw implementation errors as Z507

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

[operations/deployment-charts@master] wikifunctions: Upgrade orchestrator from 2026-05-19-223625 to 2026-06-03-020126

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

Change #1297142 merged by jenkins-bot:

[operations/deployment-charts@master] wikifunctions: Upgrade orchestrator from 2026-05-19-223625 to 2026-06-03-020126

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

@Jdforrester-WMF I still see the error, is it because it's cached?