For the record, the problem is not that the executors don’t handle tenants, but that we have some optimization logic that picks one executor or another depending on requirements (multitenancy or not, …), and in some cases that logic picks the wrong one (which doesn’t handle tenants, even though others do).

Ok, so actually @SmorgasbordQ was right. The problem is just that ByTermUpdateWorkExecutor, DeleteExtWorkExecutor, UpdateExtWorkExecutor are buggy and don’t handle tenant IDs, at least not in all cases.

@SmorgasbordQ Thanks a lot for your report and reproducer.

This is quite embarrassing, and my only relief is that we reworked that part in Hibernate Search 6 which means this will only affect Hibernate Search 5.11 and maybe 5.10 (I didn’t check yet), but not later versions.

For the record, the problem is not that the executors don’t handle tenants, but that we have some optimization logic that picks one executor or another depending on requirements (multitenancy or not, …), and in some cases that logic picks the wrong one (which doesn’t handle tenants, even though others do).

I will work on a fix.

I think I found the issue(s): ByTermUpdateWorkExecutor, DeleteExtWorkExecutor, UpdateExtWorkExecutor do not factor in a tenantId as needed.

I added a tenantId option to NumericFieldUtils.createExactMatchQuery (to conditionally build a BooleanQuery) for numericIds, otherwise when updateDocument was called, I checked the tenantId to see if a call to Utility.deleteWorkByQuery+addDocument was needed (otherwise use updateDocument with idTerm)

I’m not sure what the preferred coding practices / test cases / pull-requests are - if you’d like me to do anything more to help let me know… but otherwise I imagine this info would be enough