Merritt Sword may hand out invalid callback (update_uri) URLs that aren't valid

[sfisher]

Around the time of a downtime on July 22, when Ashley was doing ?? to servers, Merritt-sword handed us some sword-aws URLs for update_uris to use for our updates to datasets. These don't work for us when we go to http://sword-aws.cdlib.org:39001/mrtsword/edit/cdl_dryad/doi%3A10.5061%2Fdryad.2v6wwpzjz or similar things.

I'm pretty certain these URLs didn't come from us after searching through our code and all our configuration.

These URLs withsword-aws in them don't work and make updates with them fail later on when we try to use them like SWORD wants us to.

I've only seen this happen with 3 datasets and probably only around downtime or maintenance restart times.

Maybe there is a fallback or something that uses these in some specific circumstances. 🤷‍♂️

Anyway, could you all check for something like this and maybe it's an easy fix.

It's not urgent, but if these get handed out occasionally in some very specific circumstances then it'll just make us crazy in the future as things fail and we have to take time to troubleshoot the failures.

[mreyescdl]

@dloy I see reference to 'sword-aws.cdlib.org' in the config file

sword-info.txt:edit=http://sword-aws.cdlib.org:39001/mrtsword/edit/

[terrywbrady]

I am scanning our code. I see a reference here

https://github.com/CDLUC3/mrt-tomcat/blob/master/data/mrtHomes/mrt-sword01x2-prd/sword-info.txt#L7

I also see that string is the default value in the mrt-sword repo

https://github.com/CDLUC3/mrt-sword/search?q=sword-aws&unscoped_q=sword-aws

I am not sure how that value gets modified in the deployment processes.