better error loging

**yuri** · 03-19-2026, 01:45 PM

Most errors can be tracked down by enabling tracing in the log. It's how it's supposed to work.

Some log messages are not traced, if there are some important, each one should be fixed separately. There's no single engine that we can fix so all log messages are traced.

> Just what is the point of giving errors i can't track down?

There's no need to write this in a feature request other than to add more toxic tone to it.

**jamie** · 03-19-2026, 03:08 PM

It's meant to share my sense of frustration at seeing a massive amount of errors in my setup, but because of obscurity, doing anything about this is very difficult

Well, maybe it's time to have all errors feed through a single log function so they can be better handled and traced. Many of them list the offending workflow ID, and that's all I need, but without any source of reference, I am probably going to have to write my own script just to handle the shortcomings of the output

**yuri** · 03-19-2026, 03:19 PM

The all go through the standard PSR logger. In case of exceptions, they can be traced. In case of notices (just message), they can't be easily traced. We can add some context, and sometime we do add, but often it's very hard to know the exact context at it occurs very deep. We try not to use notices and prefer errors now, it's usually a legacy code that can't be changed to prevent compatibility breaks.

**jamie** · 03-20-2026, 08:28 AM

if you could just always display the workflow id that would be amazing

**yuri** · 03-20-2026, 08:35 AM

Yes, but understand the the formula function is not aware of the workflows feature neither any other potential future feature it will be called from. How it's suppose to work: when an error occurred in a formula function, it is bubbled up until it's caught by something above. I believe we do it for workflow and display the ID. Not sure if it's always the case, need to check.

For notices it's impossible to display the workflow ID.

For "Workflow: Could not get related entity by path", it's possible and we should fix it (unfortunately the fix is not trivial in this particular case). But it's really the case that is not a real error and could be even lowered to the INFO level.

**jamie** · 03-25-2026, 09:29 AM

sounds like a bit a problem with the underlying architecture, maybe its worth spending some time fixing that up

so it will be possible to get the offending workflow for these?

[2026-03-19 13:04:18] WARNING: Workflow: Could not get related entity by path 'sentBy.teams'.
[2026-03-19 13:04:18] WARNING: E_WARNING: Undefined array key 6

**yuri** · 03-25-2026, 09:59 AM

It's not a problem with the architecture. It's normal that a caller does not know about internal details about called functions if there is no tight coupling between them. Formula does not know about Workflows existence and should not know.

Warnings and notices are more a legacy of PHP and should not exist had the PHP been created today. They should be exceptions which are caught by the caller.

> [2026-03-19 13:04:18] WARNING: Workflow: Could not get related entity by path 'sentBy.teams'.

This one that we already have fixed, as it's the case where the context is known.

> [2026-03-19 13:04:18] WARNING: E_WARNING: Undefined array key 6

This one cannot be caught other than converting it to the error. PHP is likely to evolve to produce an error for this in future. Then it will be possible to catch.

Or maybe this warning is our fault in a particular place in code that we need to fix.

**yuri** · 03-25-2026, 10:26 AM

You can add a global error handler that produces an error when warning happens. This way it should print the workflow ID in the log.

Maybe we need to consider to add it but disable it by default, otherwise it will be a serios breacking change for many.

Another possible solution, is to pass the context down to be used for log printing. But it would require a significant effort that I think is not justifiable as we are moving to producing errors instead of notices, hence it will be not needed in the future. And it won't solve PHP-level notices, only app-level.

**yuri** · 03-25-2026, 10:45 AM

Changed array\at notice to the error. https://github.com/espocrm/espocrm/c...51c338238e2baf. We will need do it in other places too.

**shalmaxb** · 2026-03-26T08:18:51+00:00

This already helped me a lot: https://deepwiki.com/ You choose espoCRM as the repo ando now this AI tries to resolve any question by using the published repo content.

when I input only two lines of your error

[2026-03-19 13:00:06] WARNING: Workflow: Could not get related entity by path 'sentBy.teams'.
[2026-03-19 13:00:06] WARNING: Workflow: Could not get related entity by path 'sentBy.teams'.

Answer
## Error Message Explained

This warning means that the Workflow system is trying to access the path `sentBy.teams` but cannot find or access this relationship. [1](#1-0) [2](#1-1)

## Technical Details

### What the Path Attempts
The path `sentBy.teams` attempts to navigate from an Email entity to the sending user (`sentBy`) and then to that user's teams:

1. **Email → sentBy**: The Email entity has a `sentBy` relationship to the `User` entity [2](#1-1)
2. **User → teams**: The system then tries to access the user's teams

### Why It Fails
The problem is that the `teams` relationship is not accessible through this path in the workflow context. Although users can have teams, the relationship configuration is not suitable for traversal by the Workflow system. [3](#1-2)

### Possible Solutions
1. **Use direct user access**: Instead of `sentBy.teams`, use `sentBy` and then access the user's teams
2. **Adjust workflow logic**: Check the workflow conditions and use alternative access paths
3. **Check metadata**: Ensure the relationship metadata is correctly configured

## Notes

The warning appears twice, indicating the workflow attempt is repeated. This is a typical Workflow system warning that indicates relationship problems but does not represent a critical system failure. [1](#1-0)

Wiki pages you might want to explore:
- [Field Views (espocrm/espocrm)](/wiki/espocrm/espocrm#2.3.2)

### Citations

**File:** application/Espo/Resources/metadata/entityDefs/Email.json (L708-711)
```json
"sentBy": {
"type": "belongsTo",
"entity": "User"
},
```

**File:** application/Espo/Resources/metadata/entityDefs/Team.json (L45-53)
```json
"users": {
"type": "hasMany",
"entity": "User",
"foreign": "teams",
"columnAttributeMap": {
"role": "userRole"
},
"apiSpecDisabled": true
},
```

**jamie** · 2026-03-26T10:15:18+00:00

yuri it would be a great help to track all errors down easier I have inherited this system from someone with great enthusiasm and dev op skill, but not a strong developer background and i want to get it working very smoothly so we can track down some deeper bugs inside the system

Any idea what release some of the easier ones to implement will be in?

thanks

**jamie** · 2026-03-26T10:26:11+00:00

sweet, thanks mate!

better error loging

better error loging

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment