Select to view content in your preferred language

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

1861
6
12-06-2018 10:31 AM
Mike_Quetel
Occasional Contributor

[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: 😎 

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
Mike_Quetel
Occasional Contributor

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

Mike_Quetel
Occasional Contributor

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
Mike_Quetel
Occasional Contributor

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