-
Notifications
You must be signed in to change notification settings - Fork 490
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
native API for creating dataverse reports parse error for valid json #3533
Comments
same behavior for using "--upload-file l0.json" instead of "@l0.json" |
This works on my machine (I'm on 9024856):
However, I noticed that this doesn't (note
Stacktrace:
Line 138 is this: Same data @pameyer is using:
@pameyer which version or commit are you on? Maybe you've found two bugs! 😄 |
@pameyer closer to your original bug report, this is what I get when I use
|
As @pdurbin mentioned; "unable to reproduce" means the problem is probably on my end (and the json file does exist). Doing some additional troubleshooting before closing in the event others run into the same problem. For future reference; earlier comment about "-d @l0.json" and "--upload-file l0.json" was wrong (typo'd) - "-d @l0.json" fails and from curl docs probably inappropriate. @pdurbin 's comment in #3534 indirectly revealed the initial problem: user error when attempting to create a dataverse under the root dataverse, and using the alias for the dataverse to be created as the $id parameter, or without an $id parameter (instead of using $id=$alias_of_root_dataverse). Behavior with "-d @$filename" was identical to behavior of "--upload-file $non_existent_file" because I didn't do any form/url encoding or setting file param of the POST data in the "-d" usage (might or might not behave the same; not troubleshooting further). |
@pameyer - Did you ever find a solution to the problem? We are getting the same parse error with our test dataverse installation (though no problem with our production installation) |
@FASposito this issue was closed and I was having trouble reproducing it. I'm happy to open it back up. Can you please provide the following?
Thanks! p.s. I saw your post here too: https://groups.google.com/d/msg/dataverse-community/fKgtWBXNgBo/3-KW9qxmAwAJ |
@pdurbin ,
This is the content of dataverse.create.json:
And here is the error:
The json file works with both demo.dataverse.org and our production server, data.aussda.at. |
@FASposito I meant to mention I saw you briefly over here too: http://irclog.iq.harvard.edu/dataverse/2017-12-20 😄 It's actually pretty easy for me to reproduce the error above but I'm not sure if I'm doing the same thing you are. Check this out. If the JSON file is not present, you get the error. I'm demonstrating this by creating a new empty directory and then
Does this make sense? Is it possible that the file isn't present or that the combination of curl flags is causing the file not to be read? Rather that |
Hi Phil,
Also tried the fully qualified path on our development server just to be sure but it did not work. We have a local configuration problem for sure, just don't know what it could be. Our sys admin is working on it. Our development installation is a snapshot of our production installation, minus ssl, so maybe something was lost in translation? |
@FASposito I'm sorry I missing your comment above. Judging from the date, I was probably out the door to visit my family for Christmas. Are you still having this problem? Any update? Thanks! |
There was a recent thread about the same problem: https://groups.google.com/d/msg/dataverse-dev/dZd-Pz-2sxY/NYtPNwTGAwAJ |
To focus on the most important features and bugs, we are closing issues created before 2020 (version 5.0) that are not new feature requests with the label 'Type: Feature'. If you created this issue and you feel the team should revisit this decision, please reopen the issue and leave a comment. |
native API endpoint for creating a dataverse reports parse error for valid JSON.
curl -X POST -d @l0.json -H "X-Dataverse-key: $admin_api_key" $dataverse_host/api/dataverses/dv_alias
returns (w\ http 400):
{"status":"ERROR","message":"Error parsing Json: Invalid token=EOF at (line no=1, column no=0, offset=-1). Expected tokens are: [CURLYOPEN, SQUAREOPEN]"}
l01.json:
{
"name":"dv_name",
"alias":"dv_alias",
"dataverseContacts":[ {"contactEmail":"foo+dataverse@example.com"} ],
"affiliation":"aff",
"dataverseType":"LABORATORY"
}
jq and python 2.7.8 json library both think this is valid JSON. Could be either an endpoint glitch being reported to the user as parser error, or parser error - haven't investigated further yet.
The text was updated successfully, but these errors were encountered: