Open sfisher opened 1 month ago
This was much easier to fix today when I came back to it and was a combination of a few things:
keyword
property for exact matches.(hit)
but wasn't raising an error. I guess the logic was just checking that the method existed rather than calling it.I spent hours and hours trying to meticulously trace through 3 or 4 files of code which was convoluted on Friday, but it turned out to be small differences in how search was handled and Python not raising errors.
This is a super confusing page and code and the data we have in OpenSearch made it hard to discover if it was working.
Items with "issues" have to do with "hasIssues" and "linkIsBroken" in the search table originally.
If you select "ALL" from the list then the "issues" section of the page always tells you that you have no issues. You have to select one of the groups or owners for issues to show up correctly. This is apparently how the page is designed and is how the "working" version does things against the database.
I eventually finally found some issues in the normal database development version by selecting an items such as "Bulyon1" from the list and it shows issues in normal development.
How to be sure the data should show these errors in our OpenSearch index by:
I put in some "error" items manually from the bulyon1 group and they still don't show up.
Also the "crossref" errors may be similar. I put in these error items for crossref.
Need to troubleshoot why errors are still not showing up.