StackOverflowException generating query with many records of inlined data

If a query has to import many records of inlined data, above a certain threshold, the generation of the query fails with a StackOverflowException within Entity Framework. The following minimal code sample reproduces this issue:

using System;
using System.Data.Entity;
using System.Linq;

namespace EntityFrameworkStackOverflow
{
	class Program
	{
		static void Main(string[] args)
		{
			var ids = Enumerable.Range(1, 5000).Select(n => Guid.NewGuid()).ToList();

			var query = new Context().Table.Join(ids, record => record.Id, id => id, (record, key) => record);

			query.ToString();
		}
	}

	public class Context : DbContext
	{
		public DbSet<Table> Table { get; set; }
	}

	public class Table
	{
		public Guid Id { get; set; }
	}
}

The exception occurs on the query.ToString() line, and occurs exactly the same way if instead the IQueryable<Table> is enumerated. The stack trace at the time of the exception looks like this:

EntityFramework.dll!System.Data.Entity.Core.Query.InternalTrees.BasicOpVisitor.VisitChildren(System.Data.Entity.Core.Query.InternalTrees.Node n)
EntityFramework.dll!System.Data.Entity.Core.Query.PlanCompiler.PropertyPushdownHelper.VisitSetOp(System.Data.Entity.Core.Query.InternalTrees.SetOp op, System.Data.Entity.Core.Query.InternalTrees.Node n)
EntityFramework.dll!System.Data.Entity.Core.Query.InternalTrees.BasicOpVisitor.Visit(System.Data.Entity.Core.Query.InternalTrees.UnionAllOp op, System.Data.Entity.Core.Query.InternalTrees.Node n)
EntityFramework.dll!System.Data.Entity.Core.Query.InternalTrees.UnionAllOp.Accept(System.Data.Entity.Core.Query.InternalTrees.BasicOpVisitor v, System.Data.Entity.Core.Query.InternalTrees.Node n)
EntityFramework.dll!System.Data.Entity.Core.Query.InternalTrees.BasicOpVisitor.VisitNode(System.Data.Entity.Core.Query.InternalTrees.Node n)
EntityFramework.dll!System.Data.Entity.Core.Query.InternalTrees.BasicOpVisitor.VisitChildren(System.Data.Entity.Core.Query.InternalTrees.Node n)
EntityFramework.dll!System.Data.Entity.Core.Query.PlanCompiler.PropertyPushdownHelper.VisitSetOp(System.Data.Entity.Core.Query.InternalTrees.SetOp op, System.Data.Entity.Core.Query.InternalTrees.Node n)
EntityFramework.dll!System.Data.Entity.Core.Query.InternalTrees.BasicOpVisitor.Visit(System.Data.Entity.Core.Query.InternalTrees.UnionAllOp op, System.Data.Entity.Core.Query.InternalTrees.Node n)
EntityFramework.dll!System.Data.Entity.Core.Query.InternalTrees.UnionAllOp.Accept(System.Data.Entity.Core.Query.InternalTrees.BasicOpVisitor v, System.Data.Entity.Core.Query.InternalTrees.Node n)
EntityFramework.dll!System.Data.Entity.Core.Query.InternalTrees.BasicOpVisitor.VisitNode(System.Data.Entity.Core.Query.InternalTrees.Node n)
EntityFramework.dll!System.Data.Entity.Core.Query.InternalTrees.BasicOpVisitor.VisitChildren(System.Data.Entity.Core.Query.InternalTrees.Node n)
EntityFramework.dll!System.Data.Entity.Core.Query.PlanCompiler.PropertyPushdownHelper.VisitSetOp(System.Data.Entity.Core.Query.InternalTrees.SetOp op, System.Data.Entity.Core.Query.InternalTrees.Node n)
EntityFramework.dll!System.Data.Entity.Core.Query.InternalTrees.BasicOpVisitor.Visit(System.Data.Entity.Core.Query.InternalTrees.UnionAllOp op, System.Data.Entity.Core.Query.InternalTrees.Node n)
EntityFramework.dll!System.Data.Entity.Core.Query.InternalTrees.UnionAllOp.Accept(System.Data.Entity.Core.Query.InternalTrees.BasicOpVisitor v, System.Data.Entity.Core.Query.InternalTrees.Node n)
....

(This repeated pattern of calls continues as far as Visual Studio is willing to follow stack frames.)

[ajcvickers]

EF Team Triage: This issue is not something that our team is planning to address in the EF6.x code base. This does not mean that we would not consider a community contribution to address this issue.

Moving forwards, our team will be fixing bugs, implementing small improvements, and accepting community contributions to the EF6.x code base. Larger feature work and innovation will happen in the EF Core code base (https://github.com/aspnet/EntityFramework).

Closing an issue in the EF6.x project does not exclude us addressing it in EF Core. In fact, a number of popular feature requests for EF have already been implemented in EF Core (alternate keys, batching in SaveChanges, etc.).

BTW this is a canned response and may have info or details that do not directly apply to this particular issue. While we’d like to spend the time to uniquely address every incoming issue, we get a lot traffic on the EF projects and that is not practical. To ensure we maximize the time we have to work on fixing bugs, implementing new features, etc. we use canned responses for common triage decisions.

[ajcvickers]

@logiclrd I could give it another try. However, reading through again I missed the large number of Ids in the list. At some point EF reaches a limit as to the number of items it can handle in a single list like this. We’re not planning to make any changes to EF6 in this respect.