@gengh How can I view this error? In particular, how can I see the JS one?

This error usually means that we've run syntactically incorrect code in the Python executor. RustPython is bad at handling that class of error, so we usually see this very generic "oops bad unreachable" thing. At a cursory glance, I don't see anything wrong with the implementation itself. The JS error might be more informative.

How do we run the parser and renderer functions? If I can grab all the participating objects and recreate the call to the orchestrator, I can try to replicate this locally. So what does the Z7 for the renderer function look like?

To see this error:

• Go to https://www.wikifunctions.org/view/en/Z13713
• Expand the field "number" in the "Try this function" widget
• Open the browser console, switch to the Network tab, and clear all requests (for easy identification)
• Collapse the field "number" again
• Inspect the failed api call in the Network tab -> Response
• The error can be found in the Result envelope/Z22 object returned in "data"

Looking at the renderer function page, seems that this error only occurs when the renderer function is called with empty values:

• Go to https://www.wikifunctions.org/wiki/Z14280
• Expand the field "number to display"
• With empty values, click "Run function"
• Inspect the "Error" link
• Now, add a value in the "number to display --> value" field
• Click again "Run function"
• The function runs successfully (even without Language) and returns a result

Run with empty values:

Run with number value:

Run with number and language values:

That error looks familiar @cmassaro 💀

@gengh || @DVrandecic
When this bug did not exist, what type of error result would we get whenever we ran an empty string?

@ecarg Yep, it's the same error you were working on! Unfortunately, there will always be cases where this error crops up (usually a syntax error).

So if it's only happening when the input is an empty string, I am imagining that it's something like this:

1. executor gets its payload;
2. executor tries to run the type converter;
3. executor runs the code int(''), which raises a ValueError.

This is surprising to me for two reasons:

1. validation should catch that the input is an invalid Number, unless the Number validator allows empty strings?
2. this class of error should show up with a much more informative error string in RustPython now after some recent changes.

To trace this, it would be helpful if I could see where in the frontend code we generate the function call for the Renderer. That way, I can put together an analogous Z7 and run it locally (sadly, we still aren't logging input Z7s in the orchestrator). @gengh , can you point me to the relevant frontend code?

Ah I see~ @cmassaro
Also, until Geno comes back:/resources/ext.wikilambda.edit/components/default-view-types/ZObjectStringRenderer.vue

Thank you!!

A couple of observations:

• the validator for Natural Number is currently given as Z101, so it makes sense that these empty strings are making it to the evaluator and that we're seeing an error
• so far, when I try to replicate this locally, I see the "correct" error: invalid literal for int() with base 10: ''
• I haven't exhaustively pulled everything off of wikifunctions.org yet, so I can't be 100% certain that this can't be replicated locally and will look more thoroughly on MOnday

I have, for now, removed the parser and renderer from natural numbers, so that the error is gone.

To trace this, it would be helpful if I could see where in the frontend code we generate the function call for the Renderer. That way, I can put together an analogous Z7 and run it locally

@cmassaro the best way to see the sent Z7 is to look at the request object from the API call: same process as my first comment, but looking at the Network -> Request sub-tab instead.

In T360791#9654649, @gengh wrote:

To see this error:

• Go to https://www.wikifunctions.org/view/en/Z13713
• Expand the field "number" in the "Try this function" widget
• Open the browser console, switch to the Network tab, and clear all requests (for easy identification)
• Collapse the field "number" again
• Inspect the failed api call in the Network tab -> Response
• The error can be found in the Result envelope/Z22 object returned in "data"

You can also trigger the API call in the function evaluator widget, with an empty number value and a filled Language field and look at the Network call the same way.

Change #1014482 had a related patch set uploaded (by Genoveva Galarza; author: Genoveva Galarza):

[mediawiki/extensions/WikiLambda@master] Stop renderer field from running renderer with blank values

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

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

Catch errors in all code objects run within Python executor (including type converters).

Change #1014482 merged by jenkins-bot:

[mediawiki/extensions/WikiLambda@master] Stop renderer field from running renderer with blank values

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

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

Catch errors in all code objects run within Python executor (including type converters).

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

[operations/deployment-charts@master] wikifunctions: Upgrade evaluators from 2024-02-26-150300 to 2024-04-03-210033

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

Change #1017061 merged by jenkins-bot:

[operations/deployment-charts@master] wikifunctions: Upgrade evaluators from 2024-02-26-150300 to 2024-04-03-210033

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