Page MenuHomePhabricator

Don't hard-code English-language error messages in the orchestrator; have pre-defined custom ones
Closed, ResolvedPublic

Description

Imperfect search via rg -U "makeErrorInNormalForm\(\s*error\..*,\s*\[\s'" src

  • src/ZWrapper.js: Generic type function did not return a Z4…
  • src/ZWrapper.js: ZObject does not have the key ...
  • src/builtins.js: Object did not contain key…
  • src/builtins.js: Object did not contain key(s)…
  • src/builtins.js: An empty list has no head…
  • src/builtins.js: An empty list has no tail…
  • src/builtins.js: Provided equality function did not return Boolean…
  • src/orchestrate.js: The provided object is not a function call…
  • src/execute.js: Function evaluation returned an empty object…
  • src/execute.js: Function evaluation returned both a value and an error…
  • src/execute.js: Aborting because argument resolution contains cyclical references: ... (Will be handled by T350608)
  • src/execute.js: Could not create an implementation for…
  • src/execute.js: Could not find any implementations for…
  • src/frame.js: No argument called ' + argumentName + ' in scope.
  • src/validation.js: Builtin validator "${validationFunction.Z8K5.Z9K1}" not found for ...

Note: T292804 will be used for similar work (eliminating English errors) in the evaluator.

Event Timeline

Jdforrester-WMF changed the task status from Open to In Progress.Oct 3 2023, 2:33 PM

@cmassaro , @Jdforrester-WMF :
All the occurrences listed above have been covered now by the patches, except for one:

src/execute.js: Aborting because argument resolution contains cyclical references: ...

This one seems tough: it seems not to fit well with any of our existing error types, but also seems too specialized to warrant a new error type. Actually, the error type argument_value_error is appropriate in spirit, but it has 2 keys (key, bad value) whose values are not actually knowable. (The detected cycle could be caused by multiple keys, and the code doesn't know which keys are involved.)

One option is to keep the English string, but change the error type to unknown_type, so the use of the string would be formally legit. That's not ideal, but seems acceptable to me. Looking for input on this. If folks think this calls for a new error type, I'm happy to do it that way.

One option is to keep the English string, but change the error type to unknown_type, so the use of the string would be formally legit. That's not ideal, but seems acceptable to me. Looking for input on this. If folks think this calls for a new error type, I'm happy to do it that way.

The recursion limit one should be a bespoke type, alongside Z570/Z571 for exceeding the rate limit, I think.

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

[mediawiki/extensions/WikiLambda@master] Update function-schemata sub-module to HEAD (a3499c5)

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

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

[operations/deployment-charts@master] wikifunctions: Switch orchestrator to 2023-11-06-172159

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

The remaining unchecked example in this ticket's description will be covered by T350608 (which is in progress). Closing.

Change 971988 merged by jenkins-bot:

[mediawiki/extensions/WikiLambda@master] Update function-schemata sub-module to HEAD (a3499c5)

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

DMartin-WMF renamed this task from Don't hard-code English-language error messages in the back-end; have pre-defined custom ones to Don't hard-code English-language error messages in the orchestrator; have pre-defined custom ones.Nov 15 2023, 6:04 AM
DMartin-WMF updated the task description. (Show Details)

Change 971999 merged by jenkins-bot:

[operations/deployment-charts@master] wikifunctions: Switch orchestrator to 2023-11-06-172159

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