jquery error when loading dataset

[mbjones]

Describe the bug
When trying to view a particular dataset, a jquery error showing TypeError: response.indexOf is not a function (see details below) occurs that prevents the page from fully loading, and just shows infinite spinners on the landing page on Firefox 113.0.2. See first screenshot. The current example of this is from a private dataset on the SFWMD repository. This occurs for SFWMD curators, as well as for me. Given that it is complaining about it not being a function, it seems to me like this could be tied to our recent release, and maybe we missed a removed/deprecated method call in an upgraded library? However, I get different behavior on Firefox (113.0.2) and Chrome (114.0.5735.90).

When I try it with Chrome 114.0.5735.90, more of the page loads (see second screenshot), but this time I get both a 404 error on the metacat view service, and a later JS error -- see details below.

To Reproduce
Steps to reproduce the behavior:

1. Go to https://sfwmd.dataone.org/view/urn:uuid:98446ef9-7ad0-40ae-8ed7-2f1c5d94ca6a
2. Log in with an authorized account
3. Note that the page loads, but indefinite spinners are shown
4. See error in JS console

Expected behavior
Page should load without error

Desktop (please complete the following information):

• OS: MacOS 11.6.6
• Browser: Firefox 113.0.2
• Browser: Chrome 114.0.5735.90

Additional context

Expand to see Firefox console errors

The javascript console in my Firefox browser shows the following error:

Uncaught TypeError: response.indexOf is not a function
    success MetadataView.js:389
    jQuery 6
    renderMetadata MetadataView.js:422
    getModel MetadataView.js:217
    p/t[e]< Backbone
    before Underscore
    Backbone 4
    success SolrResult.js:411
    jQuery 6
    getInfo SolrResult.js:490
    getModel MetadataView.js:329
    render MetadataView.js:151
    showView AppView.js:265
    renderMetadata router.js:446
    execCb require.js:1635
    check require.js:871
    enable require.js:1112
    bind require.js:129
    emit require.js:1155
    each require.js:57
    emit require.js:1154
    check require.js:925
    enable require.js:1112
    bind require.js:129
    emit require.js:1155
    each require.js:57
    emit require.js:1154
    check require.js:925
    enable require.js:1112
    bind require.js:129
    emit require.js:1155
    each require.js:57
    emit require.js:1154
    check require.js:925
    enable require.js:1112
    bind require.js:129
    emit require.js:1155

Expand to see Chrome console errors

Screenshots

Firefox

Chrome

[robyngit]

I am not able to reproduce this issue. I'm guessing we were getting an unexpected response from our servers on Wednesday for some reason.

Here is where the response.indexOf is not a function error from FireFox is originating:

metacatui/src/js/views/MetadataView.js

Line 389 in 4473c90

else if ((response.indexOf('id="Metadata"') == -1)) {

In chrome, it seems we don't get that far. Before that line, it's determined that the response is an error and so we try to renderMetadataFromIndex, leading to another error trying to parse the response from Solr:

metacatui/src/js/views/MetadataIndexView.js

Line 70 in 4473c90

if(data.response.numFound == 0){

@mbjones @rushirajnenuji , do you have any insight as to what this response might have been? If we know what we were getting back, then we try to handle it better when it occurs.

[rushirajnenuji]

I was able to reproduce the issue response.indexOf is not a function initially on Chrome when @mbjones reported the issue. The view on Chrome showed infinite spinners for retrieving dataset details and metadata. (refer to the Firefox screenshot that Matt attached in the issue description).

OS: Mac OS 12.6.2
Browser: Google Chrome Version 113.0.5672.126

---

HTTP request when the error occurred:

• link address:

https://sfwmd.dataone.org/metacat/d1/mn/v2/views/metacatui/urn%3Auuid%3A98446ef9-7ad0-40ae-8ed7-2f1c5d94ca6a

• request headers:

GET /metacat/d1/mn/v2/views/metacatui/urn%3Auuid%3A98446ef9-7ad0-40ae-8ed7-2f1c5d94ca6a HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Cache-Control: no-cache
Connection: keep-alive
Cookie: JSESSIONID=512E0260EC22DB6F1CD829A189379E6C
Host: sfwmd.dataone.org
Pragma: no-cache
Referer: https://sfwmd.dataone.org/view/urn:uuid:98446ef9-7ad0-40ae-8ed7-2f1c5d94ca6a
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36
X-Requested-With: XMLHttpRequest
sec-ch-ua: "Google Chrome";v="113", "Chromium";v="113", "Not-A.Brand";v="24"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "macOS"

• response headers:

HTTP/1.1 200 200
Date: Wed, 31 May 2023 18:59:23 GMT
Server: Apache
Vary: User-Agent
Content-Length: 4121
Access-Control-Allow-Origin: 
Access-Control-Allow-Headers: Authorization, Content-Type, Origin, Cache-Control
Access-Control-Allow-Methods: GET, POST, PUT, OPTIONS
Access-Control-Allow-Credentials: true
Keep-Alive: timeout=5, max=69
Connection: Keep-Alive
Content-Type: text/json

• response:

{
  "responseHeader":{
    "status":0,
    "QTime":0,
    "params":{
      "q":"(id:\"urn\\:uuid\\:98446ef9\\-7ad0\\-40ae\\-8ed7\\-2f1c5d94ca6a\" OR seriesId:\"urn\\:uuid\\:98446ef9\\-7ad0\\-40ae\\-8ed7\\-2f1c5d94ca6a\")",
      "archived":"archived:*",
      "fl":"abstract,id,seriesId,fileName,resourceMap,formatType,formatId,obsoletedBy,isDocumentedBy,documents,title,origin,keywords,attributeName,pubDate,eastBoundCoord,westBoundCoord,northBoundCoord,southBoundCoord,beginDate,endDate,dateUploaded,archived,datasource,replicaMN,isAuthorized,isPublic,size,read_count_i,isService,serviceTitle,serviceEndpoint,serviceOutput,serviceDescription,serviceType,project,dateModified",
      "fq":"(readPermission:\"public\")OR(writePermission:\"public\")OR(changePermission:\"public\")OR(isPublic:true)",
      "rows":"1000",
      "wt":"javabin",
      "version":"2"}},
  "response":{"numFound":1,"start":0,"numFoundExact":true,"docs":[
      {
        "id":"urn:uuid:98446ef9-7ad0-40ae-8ed7-2f1c5d94ca6a",
        "fileName":"GEMM_Groundwater_Exchange_Monitoring_and.xml",
        "formatId":"https://eml.ecoinformatics.org/eml-2.2.0",
        "formatType":"METADATA",
        "size":17935,
        "archived":false,
        "dateUploaded":"2023-05-02T15:00:26.900Z",
        "dateModified":"2023-05-10T16:26:42.800Z",
        "datasource":"urn:node:SFWMD",
        "isPublic":true,
        "abstract":"GEMM is a 5 year project to understand and quantify  ground water exchange effects relatating to Florida Bay and contributing fresh water inputs.\nThe Groundwater Exchange Modeling and Monitoring (GEMM) Plan was created to provide a framework to address the uncertainties associated with landscape-scale flow patterns and impediments, SW-GW interactions, impacts of seepage eastward on GW movements south to Florida Bay, and the influence of water management on Florida Bay salinity, especially in the central Florida Bay region. A conceptual model of the drivers and interactions associated with central Florida Bay salinity (see attached work plan document) will guide the assessment of existing knowledge on GW influence in central Florida Bay, the development of a surface and porewater salinity emulator tool for coastal Florida Bay, and the collection of critical information where data gaps currently exist. \n\nThe overarching goal of GEMM is to understand how increases in water to Shark River Slough (SRS) and Taylor Slough (TS) decrease salinities in Florida Bay. There are two broad objectives of GEMM:\n1) Determine how changes in upstream water management in SRS and/or TS decrease salinities in Central Florida Bay. \n1a- Create a salinity emulator model by linking a density-dependent hydrodynamic model (BISECT) with the output of the District’s water management model (RSMGL) to evaluate SW/GW interactions.  \n1b- Conduct ecological monitoring to validate and provide accurate model inputs.  \n2) Use information from Objective 1 to evaluate both naturally occurring conditions and water\n     management scenarios on salinity in Florida Bay to predict occurrences of hypersalinity.",
        "keywords":["Ground water exchange",
          "Central Florida Bay",
          "GEMM",
          "Surface water"],
        "title":"GEMM - Groundwater Exchange Monitoring and Modeling",
        "southBoundCoord":24.625,
        "northBoundCoord":25.5,
        "westBoundCoord":-81.25,
        "eastBoundCoord":-80.125,
        "beginDate":"2022-01-01T00:00:00Z",
        "endDate":"2027-01-01T00:00:00Z",
        "origin":["Theresa Strazisar",
          "Steve Krupa",
          "Fred Sklar",
          "Kurt Saari",
          "Matahel Ansar"],
        "isDocumentedBy":["urn:uuid:98446ef9-7ad0-40ae-8ed7-2f1c5d94ca6a"],
        "documents":["sfwmd-dmarley.1157.1",
          "sfwmd-dmarley.1156.1",
          "urn:uuid:98446ef9-7ad0-40ae-8ed7-2f1c5d94ca6a",
          "sfwmd-dmarley.1159.1",
          "sfwmd-dmarley.1158.1",
          "sfwmd-dmarley.1160.1"],
        "resourceMap":["resource_map_urn:uuid:f447144b-22f2-4709-80b0-651bc892bf61"],
        "isService":false,
        "read_count_i":6}]
  }}

Other notes:

• relevant commit from Lauren :

Display the MetadataIndexView along with the raw metadata when there is no stylesheet for that metadata type (non EML and FGDC) Exclude isRepeatVisit records from all Log Agg searches

[taojing2002]

I grepped the error messages and this particular id on the log files. However, I only found some not-authorized errors associated with the pid.

Did you open the landing pages for other pids? Did they work?

[mbjones]

Not Authorized could explain why the view service failed. Is it possible that someone updated permissions, which is what allowed the problem to fix itself?

[taojing2002]

The not-authorized exceptions are all for the WRITE permission, such as:

[ERROR]: D1ResourceHandler: Serializing exception with code 401: WRITE not allowed on urn:uuid:98446ef9-7ad0-40ae-8ed7-2f1c5d94ca6a for subject[s]: public;  [edu.ucsb.nceas.metacat.restservice.D1ResourceHandler:serializeException:591]

So it is not for the view service, I think.

[robyngit]

I've added some better error handling in the MetadataIndexView.js and the MetadataView.js to handle cases where the response is something unexpected. Now at least the UI will show an error rather than an infinite spinner.