Better error reporting for Formula Script errors

[jamie]

This just doesn't cut it.

[2026-09-28 10:38:23] CRITICAL: (0) Before-save formula script failed. Function assign; Bad argument type at position 2, must be string. :: POST /Formula/action/run
[object] (Espo\ORM\Exceptions\PersistenceException(code: 0): Before-save formula script failed. at /var/www/html/application/Espo/Hooks/Common/Formula.php:88)
[previous exception] [object] (Espo\Core\Formula\Exceptions\Error(code: 500): Function assign; Bad argument type at position 2, must be string. at /var/www/html/application/Espo/Core/Formula/Processor.php:114) 

What file? What line in that file? What second argument is bad?

No, I've got to spend hours testing each line in the file i think it is, maybe i am right, maybe I am wrong. There is NO WAY to know.

i am glad to see Espo modernizing with Docker, but such obtuse, opaque error messages just aren't any use. We need to know the actual file and the actual line number; otherwise, you might as well just say

error -> an error has happened

and that is no help to anyone but that is what the error above says

[yuri]

The topic name should mention "formula script"? E.g. "Better log reporting for Formula Script errors".

The current error log reporting is fine. It prints file and line number, as well as trace. Absolutely no problem to track down where an error occurred, if it's a PHP-level error.

You might deal with a formula script level error. But there's no concept of "file" in formula script, it's a misleading detail.

---


I changed the topic name. Please try to use better topic names the next time.

[jamie]

this isn't a PHP error " Before-save formula script failed. Function assign; Bad argument type at position 2, must be string." That's a formula script error or at least i think it is, could be a JavaScript error for the amount of information it gives

or maybe you mean this PHP error?
Before-save formula script failed. at /var/www/html/application/Espo/Hooks/Common/Formula.php:88

yeah could be line 88... yeah let me just hack that for a bit see whats happening.... <3 hours later> o wait thats the PHP that handels forula... maybe it might be a problem with the formula... if only i knew what formula or what line...

i just need better error reporting, and yeah, identifying where abouts the error is located is part of that, as this is on a before save; I believe that to be a file.

But either way, it needs to show the line number and a way to locate whatever script is involved

You're welcome to adjust the titles to what you think is better to get the task done.

This kind of error when i am trying to upgrade our system to espo10 is utterly useless

[jamie]

i'd love to know if this will be looked at now that the topic is to your liking

[jamie]

just what exactly am i ment todo with this?




the logs

[2026-10-06 06:59:06] CRITICAL: (0) Error while saving metadata. See log file for details. :: POST /EntityManager/action/createLink :: /var/www/html/application/Espo/Core/Utils/Metadata.php(420)
[2026-10-06 06:59:14] CRITICAL: (0) Error while saving metadata. See log file for details. :: POST /EntityManager/action/createLink :: /var/www/html/application/Espo/Core/Utils/Metadata.php(420)
[2026-10-06 06:59:15] CRITICAL: (0) Error while saving metadata. See log file for details. :: POST /EntityManager/action/createLink :: /var/www/html/application/Espo/Core/Utils/Metadata.php(420)
[2026-10-06 07:04:57] CRITICAL: (0) Error while saving metadata. See log file for details. :: POST /EntityManager/action/createLink :: /var/www/html/application/Espo/Core/Utils/Metadata.php(420)
[2026-10-06 07:04:58] CRITICAL: (0) Error while saving metadata. See log file for details. :: POST /EntityManager/action/createLink :: /var/www/html/application/Espo/Core/Utils/Metadata.php(420)
[2026-10-06 07:04:58] CRITICAL: (0) Error while saving metadata. See log file for details. :: POST /EntityManager/action/createLink :: /var/www/html/application/Espo/Core/Utils/Metadata.php(420)
[2026-10-06 07:04:59] CRITICAL: (0) Error while saving metadata. See log file for details. :: POST /EntityManager/action/createLink :: /var/www/html/application/Espo/Core/Utils/Metadata.php(420)
[2026-10-06 07:04:59] CRITICAL: (0) Error while saving metadata. See log file for details. :: POST /EntityManager/action/createLink :: /var/www/html/application/Espo/Core/Utils/Metadata.php(420)
[2026-10-06 07:04:59] CRITICAL: (0) Error while saving metadata. See log file for details. :: POST /EntityManager/action/createLink :: /var/www/html/application/Espo/Core/Utils/Metadata.php(420)
[2026-10-06 07:05:09] CRITICAL: (0) Error while saving metadata. See log file for details. :: POST /EntityManager/action/createLink :: /var/www/html/application/Espo/Core/Utils/Metadata.php(420)
​ 

is there any chance of actual error reporting?

[yuri]

Is I told before, each case usually should be handled separately. There's no universal way to solve all cases where the error is unclear. Particularly this one is likely is logged earlier by a PHP notice or warning (you need to have the log level that catches this type). It's likely that it's not possible to catch the exact reason for this case as it's just PHP failed on file save. PHP should have logged the error with a warning.

It is better to post each case of unclear error separately in some single forum topic. Each one should be handled separately.

[jamie]

As I told you before, each case usually should be handled separately. There's no universal way to solve all cases where the error is unclear. Particularly, this one is likely logged earlier by a PHP notice or warning (you need to have the log level that catches this type). It's likely that it's not possible to catch the exact reason for this case, as it's just PHP failing on file save. PHP should have logged the error with a warning.

It is better to post each case of an unclear error separately in a single forum topic. Each one should be handled separately.

Ahh, I think this is where we have gotten our wires crossed.

This isn't about a single error. I understand that errors can come from different places and that local configuration can affect what happens.

Rather, this is about how and where errors are displayed.

The current strategy of showing a popup telling the user to check the logs, only for the logs to contain no usable information, really isn't working.

Usable errors need to be displayed in the browser, rather than being hidden away in some random log file that may or may not even exist.

If it's a configuration error, display it.
If it's a PHP error, say so.
If it's a validation error, display the validation message.

So I hope this makes it clearer what I'm asking for. This isn't about the backend log level or how much information gets written to the logs. It's about what errors are displayed to the user and how they are displayed.




PS: I fixed up your English, as I know how much you care about correct English grammar. 😄

[yuri]

> The current strategy of showing a popup telling the user to check the logs, only for the logs to contain no usable information, really isn't working.

As I mention before, it's intentional. If a future version it will be possible to show errors in the browser but it will be an option for dev environment and it will be HIGHLY discouraged to be turned on on production. It's how it should be, and it won't be changed. If a file permission error occurred on production, the user should not see it. It won't be reconsidered, as this is a firm position.

> It's about what errors are displayed to the user and how they are displayed.

The initial post was about the log messages and line numbers. But now you say it's about what is displayed to the user. It is an off topic. The Feature Request category is for concrete, explicitly described requests. I'm closing it as I'm tired and don't wan't to continue any further.

---

For now, I can only suggest the following: If any log message (one that is logged in the file) is hard to track down, just post it in general category. We'll try to improve each one if possible.

[jamie]

Why are you so keen on hiding useful errors from users?

They aren't as stupid as you seem to think they are, and a good error message can often help someone identify and fix a problem themselves.

When the only response they get is **“check the logs”**, that is completely useless to them. It then means I have to stop what I'm doing, go and retrieve the logs, and explain to them that they simply missed a variable.

That's an utter waste of everyone's time.

This should be a very simple fix if the actual error is something like **“required variable X is missing”**. Just tell the user that.

I genuinely don't understand why you seem so opposed to providing useful error feedback to the user, instead of hiding everything behind a generic “check the logs” message.

Why waste everyone's time by forcing the user to come back to me for help with something that could have been resolved immediately by displaying the actual error?

I'm not asking for every internal detail or stack trace to be shown to the user. I'm asking for **useful, understandable error messages** to be displayed where the user can actually see them.

That would save the user time, save me time, and make the system considerably easier to use.

[jamie]

Why are you so keen on hiding useful errors from users?

They aren't as stupid as you seem to think they are, and a good error message can often help someone identify and fix a problem themselves.

When the only response they get is **“check the logs”**, that is completely useless to them. It then means I have to stop what I'm doing, go and retrieve the logs, and explain to them that they simply missed a variable.

That's an utter waste of everyone's time.

This should be a very simple fix if the actual error is something like **“required variable X is missing”**. Just tell the user that.

I genuinely don't understand why you seem so opposed to providing useful error feedback to the user, instead of hiding everything behind a generic “check the logs” message.

Why waste everyone's time by forcing the user to come back to me for help with something that could have been resolved immediately by displaying the actual error?

I'm not asking for every internal detail or stack trace to be shown to the user. I'm asking for **useful, understandable error messages** to be displayed where the user can actually see them.

That would save the user time, save me time, and make the system considerably easier to use.