Complete record does not display

Project:RUcore/NJDH/Partner Portal Search
Version:7.6.1
Component:User Interface - Service Agent
Category:bug report
Priority:critical
Assigned:chadmills
Status:closed
Description

I pulled up this record in SOAR: <a href="http://dx.doi.org/doi:10.7282/T3KK9DN4" title="http://dx.doi.org/doi:10.7282/T3KK9DN4">http://dx.doi.org/doi:10.7282/T3KK9DN4</a>
I click on Complete Record.
I get the message: "An error occurred while attempting to load this metadata section"

See attached.

The same thing happens in RUcore portal

Comments

#1

Assigned to:Anonymous» jjotto
Status:active» test

I looked into this. The Get API is being used by the Complete Record display. The MODS xml being returned was 4 bytes short, truncating the XML and making the XML not valid. I downloaded the complete MODS datateam and added it to an existing object on the dev system in an attempt to duplicate the issue. That didn't prove to be useful as the MODS datastream was successfully used by the Complete Record display on the dev system. I then replaced the MODS datastream on the production system with the same data. It is now working in the Complete Record display. Please test it is working as expected. I still do not know what caused the issue to begin with.

#2

Version:7.7» 7.6.1

#3

Version:7.6.1» 7.7
Assigned to:jjotto» Anonymous
Status:test» active

I just came across this record in a Google (Scholar?) search: <a href="https://rucore.libraries.rutgers.edu/rutgers-lib/41775/record/" title="https://rucore.libraries.rutgers.edu/rutgers-lib/41775/record/">https://rucore.libraries.rutgers.edu/rutgers-lib/41775/record/</a>

The google scholar link took me to the complete record, with the same error message.

I was doing a google search on: rutgers roberto gonzales-ibanez

I did notice both this record and the one reported originally have diacritics in author name. No idea if that is the problem, but I'll just mention it.

#4

Assigned to:Anonymous» chadmills

Same story. The MODS datastream being return is 2 bytes short of the real size of the MODS datastream, thus dropping the closing tag in the XML.

#5

Assigned to:chadmills» Anonymous

This is fixed on the record first reported, but there is still a problem with the record cited in Comment #3. In fact, I can pull up this record from Google (not google scholar) and will be put into the complete record (with error message). Then, when I go from that screen into the *full* record, and copy/paste the name Gonzalez-Ibanez from there into the SOAR search box (searching Full Record), I get zero results. In RUcore, I get the record I'm looking for (#41775), using the default search. So there seem to be a few things going on here.

#6

Assigned to:Anonymous» chadmills

If you search "González-Ibáñez" you get three records in SOAR. Overall the searching is a separate issue. Let's keep it separate from this issue so things don't get out of hand. Please issue a separate report about the searching if you expect "González-Ibáñez" and "Gonzalez-Ibanez" to return the same records in a search.

#7

#41775 is now fixed. I did this by adding back the same MODS datastream that already existed in the object. I used the dlr/EDIT MODS editing feature and just committed the same MODS xml with now changes. The previous one I replaced the datastream.

So now this makes two objects where the MODS datastream wasn't being returned using the Get API properly but after updating with the same data everything works as expected. Both of these objects only had one version of the MODS datastream, the original. My guess is that there are more like this.

I am starting to wonder if the FOXML contained the MODS datastream is being ingested with an issue or not. Extra whitespace or something like that. I am not sure. Looking at the original FOXML doesn't reveal much.

#8

I just received the same error when displaying the complete record of an ETD that was ingested this summer: rutgers-lib:47351. I searched RUcore for "delossantos". There are no diacritics.

#9

I fixed #47351 like the other. Basically replacing the existing MODS datastream with the same one. The issue was the same; the reported size of the first version of the MODS datastream was 2 bytes short of reality which meant the closing XML tag was not returned causing the message seen on screen.

I still do not know the cause. I am thinking the way the MODS is structured in the FOXML is problematic at times.

I repeat this isn't related to any searching issues or diacritic searching.

I noticed when replacing an inline datastream using dlr/EDIT the size attribute in the foxml:datastreamVersion element isn;t supplied. I will open a separate issue for that in dlr/EDIT.

Diffing the two MODS datastreams shows the only difference is the closing </mods:mods> element in the original is not on a separate line. In the newer; reingested version the </mods:mods> element is on a separate line.

Original MODS

<mods:identifier type="doi">doi:10.7282/T3125VGM</mods:identifier></mods:mods>

New version of MODS

<mods:identifier type="doi">doi:10.7282/T3125VGM</mods:identifier>
</mods:mods>

The only fix I can really do is not trust the size of the inline datastreams determined by XPATH for the latest version and using strlen() to calculate since it appears to "sometimes" be a couple of bytes short. Another strategy might be to determine why some of these MODS datastreams are falling victim to this while others are not.

#10

Status:active» fixed

I tested all of the MODS datastreams on production. I do not think anymore exist with this issue.

Here is the report.

https://software.libraries.rutgers.edu/node/3228

This doesn't mean moving forward new resource might not have the problem. I will leave this issue fixed for now.

#11

Version:7.7» 7.6.1
Status:fixed» active

I received a report of more production with this issue. Since the MODS datastream were tested and found to all be valid I started looking at the retrieval method used by the record display. The current process analyses the MODS after retrieving using a cURL connection. This seems to be fraught with issues and is the cause of the problem. I am currently running a report using this specific retrieval method on production and test systems.

The fix would be to use a more dependable method for retrieving the MODS datastream. I have already tested replacing the method on the dev system and it works against the known problematic records on production. Once I have a complete list of test records we can test this solution ore thoroughly.

I recommend a hot/quick fix off of 7.6.1 be implemented since we are still in the 2 week post install window.

#12

1643 resources on production currently display the error in the Complete Record. List is attached.

#13

Attached is a list of 299 test resources that currently display the error. This report can be used to verify the fix works.

#14

Assigned to:chadmills» pkonin
Status:active» test

Peter,

Please help me with testing this bug. Before I implement the fix on test please look at the following. This demonstrates the issue that is being fixed.

http://rucore-test.libraries.rutgers.edu/rutgers-lib/10036/record

Under the heading "Descriptive" you will see an error message. The records listed in the attachment under comment #13 all should have this issue on the test system. You do not need to check them all. Only a few. Once you have a handle on the error let me know and I will put the fix in the place. Once in place the Descriptive metadata should appear and the error message should go away.

Thanks,
Chad

#15

Peter,

I put the fix in place on test. Please proceed.

Thanks,
Chad

#16

Status:test» fixed

#17

Assigned to:pkonin» chadmills

#18

Status:fixed» closed

Implemented on staging and production on 9/23/15. Tested on production using the error report attached in comment #12.

Back to top