Visibility attributes not updated when ingest.reingest.force_on_same_marc flag is enabled

[Jeff Davis]

EG 3.0+

If the ingest.reingest.force_on_same_marc flag is enabled, visibility attributes are not updated like you might expect when a record is modified. In particular, this includes additions or modifications to located URIs: if you add a new record with a located URI scoped to SYS1, for example, the record will not appear in SYS1 search results.

The reason is that the asset.cache_copy_visibility db function can't update bre.vis_attr_vector in this scenario without causing a trigger loop. This is a known issue, and there is a warning about it in the upgrade notes:
http://docs.evergreen-ils.org/3.0/_evergreen_3_0_3.html

But the warning is easy to miss. Since this behavior is unexpected and a few EG admins have run afoul of it, I am opening a bug report.

Ideally, we'd find a way to update bib vis attrs without getting stuck in a loop. At a minimum, increased awareness of the current behavior (e.g. by having an open bug report to point to) is helpful.

[Dan Wells (dbw2)]

Ran into this issue within the last week. Thanks for filing this, Jeff. I'd love to see this fixed somehow, as the current outcome is surprising.

See also bug #1730758 for history of this behavior.

[Josh Stompro (u-launchpad-stompro-org)]

EG 3.3.4, just upgraded from 2.10 about 2 weeks ago. Just ran into this issue with ebook titles added since the upgrade.

I'm not sure why we had 'ingest.reingest.force_on_same_marc' enabled, probably just for convenience when re-indexing.

We noticed it because ebook bibs that had been added after the upgrade were showing up to staff in other systems. The vis_attr_vector didn't include the LURI info, set to '{268435557}' instead of '{268435557,101}' for example.

Used a variation of the example upgrade sql to update the vis_attr_vector for bibs added or edited since our upgrade.

update biblio.record_entry
set vis_attr_vector = biblio.calculate_bib_visibility_attribute_set(id)
where create_date > '2019-10-19'::timestamp
or edit_date > '2019-10-19'::timestamp
;

If the problem is that each update of vis_attr_vector triggers another reingest, then would it work to add in some checks to only update bre.vis_attr_vector if the value is different than what is already there? So the update only happens the first time?

             UPDATE biblio.record_entry
               SET vis_attr_vector = biblio.calculate_bib_visibility_attribute_set(NEW.record)
               WHERE id = NEW.record
               AND vis_attr_vector is distinct from biblio.calculate_bib_visibility_attribute_set(NEW.record);

[Mike Rylander (mrylander)]

That's a good idea, Josh. I'll see if I can come up with a patch we're happy with, that hopefully only has to call the function once.

[Mike Rylander (mrylander)]

Here's a branch to consider: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1798910-update_bib_vis_on_same_marc

[Rogan Hamby (rogan-hamby)]

Tested against a fresh copy of master this is causing a failure to update the biblio.record_entry row when a bib record (at least with located URIs) is updated.

This is what I'm seeing in osrferror.log https://pastebin.com/gBVQSDvN

After reverting the change the system goes back to saving normally.