Implicit limit warnings not surfaced inside certain computeds

[jackfischer]

follow up from discord

• EdgeDB Version: 3.1-3.4 and 4.0-dev.7662+8e24887
• EdgeDB CLI Version: 3.4.0+4d95a2c
• OS Version: macos 13.1

Steps to Reproduce:

insert B {
  a:=(select {(insert A{name:="1"}), (insert A{name:="2"})}),
  aa:=(select {(insert A{name:="1"}), (insert A{name:="4"})})
};

select (
 group
    (select B).computed
   by .name
);

This produces the expected output with two members in the name: 1 group

{
  {
    key: {name: '1'},
    grouping: {'name'},
    elements: {default::A {id: 0450407c-219c-11ee-9b47-9f4e0e6b7acc}, default::A {id: 04505d82-219c-11ee-9b47-67e35ba922f8}},
  },
  {key: {name: '2'}, grouping: {'name'}, elements: {default::A {id: 045063c2-219c-11ee-9b47-0b14cb3b3042}}},
  {key: {name: '4'}, grouping: {'name'}, elements: {default::A {id: 045059a4-219c-11ee-9b47-4ba9333c026a}}},
}

3. \set limit 1, re run groupby query

{{key: {name: '1'}, grouping: {'name'}, elements: {default::A {id: 0450407c-219c-11ee-9b47-9f4e0e6b7acc}}}, ...}

Implicit limit warning is present on the outer groups set but not inside the grouping where the ...2f8 object is missing.

This only seems to happen with a computed. I have a more complicated scenario where the top level group is also missing w/o warning but unfortunately wasn't able to reduce that. Hopefully this is enough to reproduce.

Schema:

    type A {
        required property name: str;
    }

    type B {
        multi link a -> A;
        multi link aa -> A;
        multi link computed := distinct(.a union .aa);
    }

[jackfischer]

This affects the UI as well as the CLI.

[jaclarke]

@msullivan I think this is a compiler bug? My understanding is that the implicit limit should only apply to sets in the final output (so you don't do something like accidentally return the entire database in the repl), but not to any intermediate sets since that would actually alter the meaning of the query right?

edgedb> create database limitbug;
OK: CREATE DATABASE
edgedb> \c limitbug
limitbug> create type Test {
.........   create multi property nums := {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}
......... };
OK: CREATE TYPE
limitbug> insert Test;
{default::Test {id: b86a4508-270f-11ee-a783-cf395d7df4f1}}
limitbug> \set limit
limit: 100
limitbug> with nums := Test.nums
......... select count(nums);
{10}
limitbug> \set limit 5 # Note: CLI actually sets limit to 6, so it can show message if result len > 5
limitbug> with nums := Test.nums
......... select count(nums);
{6}  <-- This is incorrect right? The count should still be 10
limitbug> with nums := Test.nums
......... group nums
......... using is_even := nums % 2 = 0
......... by is_even;
{
  {key: {is_even: false}, grouping: {'is_even'}, elements: {1, 3, 5}},
  {key: {is_even: true}, grouping: {'is_even'}, elements: {2, 4, 6}},
}
limitbug> \set limit 100
limitbug> with nums := Test.nums
......... group nums
......... using is_even := nums % 2 = 0
......... by is_even;
{
  {key: {is_even: false}, grouping: {'is_even'}, elements: {1, 3, 5, 7, 9}},
  {key: {is_even: true}, grouping: {'is_even'}, elements: {2, 4, 6, 8, 10}},
}

[jackfischer]

Another simpler example of the implicit limit being applied on an inner query instead of the final output result (possibly comparable to the with nums := Test.nums example above)

select (select SomeType filter...).somePath.withLowCardinality

The overall results are tiny and < the implicit limit, yet lifting the implicit limit changes the results.