ServiceFeatureTable.QueryFeaturesAsync() error - Invalid URI: The Uri string is too long

982
6
12-06-2018 10:31 AM
MikeQuetel1
New Contributor III

[EDIT2]  Esri tech support has logged BUG-000118762 in reference to this issue

[EDIT]  Visual studio project added, which demonstrates issue

This behavior is with .NET Runtime 100.4

When querying a service feature table using a complex geometry, the QueryFeatureAsync() method throws an error (shared below) which indicates that the Uri is too long.  I can regularly run simpler geometries through this code, so my assumption is that there is a problem with the volume of information being handled when this method URL encodes and/or attempts to post to the server.

The query parameters sent into the query is straightforward, consisting of the geometry and a spatial relationship of intersects.  As I mentioned, the geometry is a complex one. Something like a 244 part polygon consisting of about 24,500 points.  I've attached the JSON for this polygon below as buffers.json.

You can point the query with that geometry at this endpoint:

Layer: Taxlots (ID: 8) 

As an aside, this issue sounds alot like a post on stack overflow related to System.Net.Http.HttpClient. I don't see anything actionable in there since the exception is being thrown out of an Esri method.

Here is the error:

HResult: -2146233033
Message: "Invalid URI: The Uri string is too long."
Source: "Esri.ArcGISRuntime"
StackTrace:

   at Esri.ArcGISRuntime.ArcGISException.HandleCoreError(CoreError error, Boolean throwException)
   at RuntimeCoreNet.GeneratedWrappers.Interop.CheckError(IntPtr errorHandle, Boolean throwOnFailure, GCHandle wrapperHandle)
   at RuntimeCoreNet.GeneratedWrappers.CoreTask.Get()
   at Esri.ArcGISRuntime.Internal.CoreTaskExtensions.TaskCompletedCallbackHandler`1.OnCompleted(Object sender, EventArgs e)
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Esri.ArcGISRuntime.Internal.CoreTaskExtensions.TaskCompletedCallbackHandler`1.<CreateInternal>d__7.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Esri.ArcGISRuntime.Data.ServiceFeatureTable.<QueryFeaturesInternal>d__45.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   at MapWorks.LayerSelection.SelectableItem.<ExecuteQuery>d__35.MoveNext() in C:\GitHub\MapWorks\MapWorks\LayerSelection.xaml.cs:line 1285‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Thanks for your assitance!

6 Replies
MikeQuetel1
New Contributor III

I've also opened a tech support case: Esri Case #02231288  for this issue.

0 Kudos
MichaelBranscomb
Esri Frequent Contributor

Hi,

Thanks for reporting this issue - the team is investigating in our current sprint (I've linked your Support BUG report above to our internal development issue).

Cheers

Mike

MikeQuetel1
New Contributor III

Michael Branscomb‌  We talked at the recent dev summit and I was inquiring if this issue was fixed in the upcoming release.  The scope of this issue was that a query parameter object is provisioned with either a very complex geometry or a where clause that is very long such as an IN statement with many values.  Each scenario could cause the error reported here.  Thanks for the update.

0 Kudos
DavidHaines
Occasional Contributor

Has this been confirmed to be fixed in 100.5?

0 Kudos
MikeQuetel1
New Contributor III

It seems to be fixed in my use cases which were: query via geometries with very high vertex counts as well as where clauses such as [field] IN (1,2,3,....1000,1001)

0 Kudos
MichaelBranscomb
Esri Frequent Contributor

Hi,

Yes - this was fixed in v100.5.

Cheers

Mike

0 Kudos