Layer failing to load in Field Maps app only

[NicoleV]

Hello all,

I have an issue with a layer failing to load in the Field Maps iOS application. The layer loads perfectly fine in the accompanying web map and also in a Web App Builder application. This is the error it is throwing:

Domain: com.esri.arcgis.runtime.error
Code: 10018
Description: Invalid cast.

I found this post  but I ran a Domain Check in data reviewer and there were no attributes that did not meet domain requirements. A different issue I've seen where the layer was not loading in Field Maps (with a different error code) was where the domain field type and the field type of the attribute were not matching, but that is not my issue either. 

Also, I found this documentation but this is a line layer so it is not using any marker symbology so that's not it.

I am fully at a loss so any ideas or suggestions would be much appreciated!

[NicoleV]

I had that thought as well that the apostrophe could be the issue. However, I have other layers that use this same field and domain combination and they are loading just fine in the same Field Maps map. I'll have to dig deeper into my other domains but like I said I did a data reviewer Domain Check on this layer and it returned no errors so I feel like that roots out the issue being with the domains. 

[MitchellGrafstein]

Is it just one map in particular with the issue in Field Maps?  Or is it multiple maps that have the layer not loading in Field Maps?  We could take a look at the webmap JSON to check if the mismatch is on that end.  Also, if you add this layer to a new map, just add the one element to the form, does it fail the same way?  

[NicoleV]

I did attempt to put the same layer in a different existing field map and it failed to load in that one as well. I also made a new map and just added that layer and it's having the same behavior. 

[MitchellGrafstein]

Any chance you can share the webmap JSON?  Just curious to see how it's being pulled in by the software, then we can compare that to the layer's JSON and just see if they look any different.  (We're really at the step-by-step troubleshooting and/or put in a ticket with Esri part of the process here it would seem.)

[NicoleV]

Well here's an update...

Did some more digging in my layer and found that 3 fields had a differing field type from the domain field type. I was focused on the "Maintained By" field because that was newly added so initially thought that was the problem. However, we also had a version of the layer published to our REST that did not have that new field added, so when I tested that layer in Field Maps and it was also failing to load, I knew it was not being caused by this new field.

Initially I created a copy of my layer and then removed all the domains that did not match field types, published that layer and pulled it up in field maps and it loaded!

Looking back at the field and domain combinations, I realized I had one field that was numeric and the domain was a text, whereas all the other fields were vice versa. So once I did another test with just removing that specific domain and it loaded properly in field maps I thought I had finally found the culprit. However, once we detached the domain from the field in the enterprise layer, I got a completely different error. 

Domain: com.esri.arcgis.runtime.error
Code: 3079
Description: Domain exists.

According to this esri support documentation this has a few causes. However, we completely disconnected the field and the domain so not sure how the data-type mismatch is still causing this error. We did the steps in the solution and are still getting the same error.

It's definitely not ideal but at this point we believe the only path is to do some schema updating using X-Ray to ensure there are no more data-type mismatches between fields and coded domains. 

[NicoleV · Accepted solution]

Updating the schema worked. Since we did it this way still not exactly sure what specifically was the cause of the error was. We are just assuming it was either a different field/domain data type mismatch or the fact that the shared domain was no longer attached the the field but was still stored in the database??

[MitchellGrafstein]

Glad you were able to fix the issue.   Unless you were able to dig into the database itself, it would be hard to inspect that last part.  It would be nice to know exactly what the cause was, but sometimes it is just nice to have an issue resolved and know you can resolve it if it appears again. (Seems like it would be the mismatches, only based on the descriptions in the wild, but hard to tell for sure.) Appreciate the back-and-forth on this.

[NicoleV]

Yes very true, we are just glad to get the layer back up and running so our field staff can finally use it! Thank you for your guidance, it really helped me narrow things down!

[MitchellGrafstein]

Most welcome, happy to help. 🙂