Error: FAIL-13

82 views
Skip to first unread message

elijah....@gmail.com

unread,
Mar 17, 2022, 10:59:22 AM3/17/22
to xnat_discussion
A user recently reported this issue with one of their sessions. They are unable to archive this clinical scan due to the following error. It seems to suggest that there is a pre-existing session, but no such session exists. I've tried archiving it to a private test project on our dev server and get the same error.



Merging the uploaded data into the pre-existing session will fail for the following reasons:

FAIL-13         [field -> xs:string, Must Be Less Than 255 Characters : Current Length (369), xnat:mrSessionData/imageSessionData/subjectAssessorData/experimentData/fields/field[0]/field, The content of element 'xnat:experimentData_field' is not complete. '{"http://nrg.wustl.edu/xnat":field}' Must Be Less Than 255 Characters : Current Length (369)]

Charlie Moore

unread,
Mar 17, 2022, 11:49:34 AM3/17/22
to xnat_discussion
Hi there,

The issue you're running into is:
1. XNAT wishes to extract something from the DICOM elements and store it in the database.
2. ...But the field in the database is limited to 255 characters, while the element is 369 characters.
3. Creating the experiment fails.

This is the ticket for the issue: https://issues.xnat.org/browse/XNAT-6064 . I'm not sure exactly which elements end up getting stored in "fields" on the session object, so it's possible that the element causing the problem for you isn't (0032,4000), but that's where I would start. As of right now, the only workaround I'm aware of is to just truncate that element in the headers before uploading to XNAT. Hopefully that helps.

Thanks,
Charlie

Richard Cole

unread,
Mar 17, 2022, 12:14:50 PM3/17/22
to xnat_di...@googlegroups.com
Would site anonymization to "delete" the offending DICOM header allow for the upload?   If it's something that is not needed...

I don't think there is a "truncate" Dicom Edit function, but that would be nice..





--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/c5f81378-0eb2-4b3d-a853-3dcb3a1d71d2n%40googlegroups.com.

Charlie Moore

unread,
Mar 17, 2022, 12:32:46 PM3/17/22
to xnat_discussion
"Would site anonymization to "delete" the offending DICOM header allow for the upload?":
I hesitate to say "unconditionally yes" as there are a lot of subtleties with anonymization, including interactions with the various upload paths. That said, roughly, yes I would expect that to work. It certainly did work for me doing a quick test with site anon + compressed uploader. YMMV

"I don't think there is a "truncate" Dicom Edit function, but that would be nice.."
True, but there is a substring method and a match method. I'm not sure how resilient the substring method is to values that are smaller than the endpoint of the substring indices, but if that doesn't cause a problem, you could probably "make" a truncate method using substring. If that doesn't work, match probably would, but I'm no regex expert :).

Thanks,
Charlie

elijah....@gmail.com

unread,
Mar 17, 2022, 12:39:29 PM3/17/22
to xnat_discussion
That field has about 20,000 characters in our header, so I'm not sure where it's getting 369 from ... but either way the error makes sense now. Also I notice the LT VR in the DICOM spec allows for 10240 characters.... so I'm not sure how they managed to squeeze 20000 into this DICOM header in the first place.... but that's a different story haha.

Thanks,
-Eli

Reply all
Reply to author
Forward
0 new messages