I think if we log an error it should be as precise as possible. your logging is in do_search where we only have the filter and do not know which attribute was rejected. Couldn't the logging occur in "slapi_filter_schema_check_inner()" ?

Thanks @lkrispen good point. The rework of the patch is not immediate and will need further tests.

Yeah, the check in schema_check_inner makes more sense, but we want to check that the schema transaction lock is a rwlock not a mutex, else the err log write could cause a delay.

Okay, I can confirm that the schema locks in question are from attr_syntax_read_lock() which calls slapi_rwlock_rdlock(). So this is fine.

The second concern is that the slapi_log_err does hit a single mutex, so this could cause delays in operations if there is a high number of invalid filters being issued to the server. I think perhaps that leaving this as notes=F, and the result message we send to the client is enough, we may not need an extra log as we already provide one in the access log .....

@tbordaz ?

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This pull request has been cloned to Github as issue and is available here:
- https://github.com/389ds/389-ds-base/issues/4317

If you want to continue to work on the PR, please navigate to the github issue,
download the patch from the attachments and file a new pull request.

Thank you for understanding. We apologize for all inconvenience.