Unable to submit SOME (but not all) completed forms due to rollback error

[Galen_S_MnDOT]

Hoping one of you GeoNet Good Samaritans can help me identify the cause of my Survey123 'submission rolled back' issue.

• Survey123 version: 3.13.249
  
  
• XLSForm is attached.
  
  
• Publishing context:  the AGOL feature service in use with this form was created when an earlier version of the form was published, using the previous version of Survey123 Connect.  I've since had to re-build the Excel form in this version of Connect because of a different issue that arose when the app updated, but am still using the original AGOL feature service. 
  In fact this current XLSForm was created from the feature service (hence all the esriFieldType bindings), and then manually adapted to match its original  specifications (calculations, relevant expressions, field labels, etc.)
  
  
• I'm highly confident that the problem is caused by one of the fields in the F1, F2, or F3 element sections (all three of which should be identical save for their F# designations).  When the form is filtered to just include the parent inventory record details and the Truss and Connections sections, it submits without any problems.
  
  I'm also fairly certain that it's one of the esriFieldTypeInteger-binded questions that's the problem here.  I've already tried creating and publishing a copy of the form that has all the 'esriFieldTypeString' and '255' values cleared in the bind::esri:fieldType and bind::esri:fieldLength columns, but that didn't solve the problem. 
  
  Most/all of the questions with esriFieldTypeInteger binding have to retain that value, because otherwise the form tries to default their saved values to strings and that conflicts with the existing feature service's field types and prevents Connect from publishing it.
  
  Lastly, I've already gone through and compared the field types and other parameters in the feature service's relevant table and the form and can't seem to spot any mismatches, so I'm still stumped for now.  I've attached a zipped file geodatabase with the point feature class and related (repeat) tables from the live feature service (I can't give anyone access to that because it's protected behind my agency's AGOL organizational account), but as indicated above I'm highly certain the problem lies somewhere in the 'inspection_details' table.

Many, many thanks to any hunters that can sniff out the culprit here!  If no one manages to, I can ultimately delete the existing feature service and republish it fresh via Survey123 Connect.  However I'd strongly prefer not to do that since that would require repeating a lot of work on the feature service post-publishing and I'm trying to keep the feature service independent of any one specific version of the form.

Much obliged!!

Galen S. - MnDOT

P.S. Thanks to @Anonymous User for the info on question submission guidelines!

[DougBrowning]

First thing I would try in on your rating calcs fields like element1Ratings is to set the bind::type field to int.  This binds it in the form where the Esri bind is only for submission to the service.  My guess is your calc is doing a concat with the + instead of a add.  Then when it tries to submit that it is not a number or too big a number.   Change it to a note and you will see what it is doing.  Try this on all the calculates.

When using calculate I always set the bind type or nothing works right.

Hope that is it

[Anonymous User]

The user can't change the field type as it's an existing service. It's either that the way the calculations have been handled has changed  and it's submitting string instead of integer (which is true after one of the more recent version updates), or the user has only just now entered an invalid input combination and the survey was always flawed. 

I agree that users do not need to set the binds unless there is an explicit cause. It's a common scenario for the rollback error but may be being conflated here.

[DougBrowning]

bindtype int does not change the service type at all.  He has bind esri set to int already so this is not type change.  

[Anonymous User]

ah - i was thinking of the esri bind type

[Anonymous User]

Does the issue persist if you publish the survey anew, without the existing service and any bindings?

Given the size and complexity of the survey it would be good to narrow down the issue as much as possible. Can you get the logs from the field app when the error occurs?

https://doc.arcgis.com/en/survey123/desktop/get-answers/troubleshootgetanswers.htm#ESRI_SECTION1_C17...

do you know what the original version was when it was published? There were some changes to the way calculations are handled at some point between... 3.10 -3.12? 

Or maybe the calculations are putting in invalid answers. E.g. row 101 the calculate question has 1.5 multipliers in a calculation and the field type of small integer. This should only allow whole values, so if the input is decimalized (or string somehow due to expression) I can see it being invalid.

Also - thanks for the detail and form. 

[Galen_S_MnDOT]

Thank you @DougBrowning and @Anonymous User for your ongoing assistance with this issue!

I've been doing some testing all morning based on your responses above and unfortunately the rollback error is still present.  I thought I might have found the cause when Doug's first message pointed me toward the rating count calculations at the end of the survey and I noticed that two of those six fields had been improperly created as text fields in the feature service.  I deleted the two original fields and re-created them as integer attributes (and had no troubles re-publishing the form with both Esri and form integer bindings now added to the EXLSForm), but unfortunately that correction didn't seem to have any effect on the rollback error.

Likewise I also converted all those 'element#Ratings' from 'calculates' to 'notes' - this doesn't seem to have any effect on the final structural rating calculation - and the rollback error still occurred after that update too.

Chris, I don't think the formulae you indicated in rows 101, 245, and 389 should be causing any problems.  Those if/else calculations ingest decimals, but all of their potential outputs should be properly limited to integers (which matches that field's binding).

I'm including the log file from my iOS version of Survey123 (made sure to activate error tracking before completing and trying to submit an inspection), as well as the (slightly) updated version of XLSForm.

----------------------------

Although... something I just happened to notice while re-examining the fields in my feature service... looks like the f#_critNuts_rating fields (lines 106, 250, and 394 in the form) were incorrectly created as text fields in the original feature class even though they function as integer fields in the form (as all the '####_rating' fields should).  I'm going to fix those the same way I corrected the two erroneous 'element1rating' fields and see if that fixes it!

[Galen_S_MnDOT]

Update - fixing the f#_critNuts_rating field types hasn't seemed to have any effect either, so I'm going ahead and using the publish function to create an entirely fresh feature service on AGOL based on the current XLSForm to see if the rollback error is still present when completing inspections for that service.

[Galen_S_MnDOT]

Blast!  The issue persisted even after publishing a brand-new feature service.  I really thought that would've negated whatever was causing the problem. I'm attaching the log file for an attempt to save a submission to that new service.

Not sure if the issue is still bindings here though, since when I published the first (working) feature service, I didn't have any form or Esri binding specified.  I'm going to try a fresh publish again, with both those binding columns completely cleared in the XLSForm.

[Galen_S_MnDOT · Accepted solution]

@DougBrowning and @Anonymous User - SUCCESS! 

In the course of creating another fresh, new feature service via publishing connect, I was able to leave the bind::esri:fieldType values set to 'esriFieldTypeInteger' for those rating fields I absolutely needed to be created as numerical values in the feature service.  It seems making sure the bind::type column was clear of any values was the critical factor here. 

I couldn't even get the form to properly convert in Connect if I had 'int' specified in any of the fields that made use of the 'elem_condition' choice list; Connect would just pop an undefined 'Unable to Convert' error without any other details.

Anyhow, I've tested the newest version of the online form both by submitting a new, not-in-inventory record and one based on an existing structure, and both synced with the server without issue.  I made sure to have the app running diagnostic logging while I was running both tests, and have attached that log here.  Hopefully one of the devs can compare the first two logs in this thread against the third to find out precisely what was causing the rollback error (and why it ultimately went away).

I'll keep testing to make sure the error has indeed disappeared and will post any subsequent details here.  If it is well and truly 'solved', I'll flag this last message as the solution myself (if I can).

Thanks again for your help!

Galen S.