NullPointerException when adding a subquery

Hi, I met an exception when I tried to add the following subquery into TigerGraph. I am not sure what the problem is. Would someone please give any help? Thanks.

Here is the subquery:

 208 create query edge_22(vertex<node> n0, vertex<node> n1, vertex<node> n2, vertex<node> n3, vertex<node> n4) for graph GG returns (int) {
 209   SumAccum<int> @@n_matchings;
 210   N0 = {n0};
 211   N1 = {n1};
 212   N2 = {n2};
 213   N3 = {n3};
 214   N4 = {n4};
 215
 216   S = select s from N3 -(revlink)-> node:s where
 217         s.neighbors("revlink").contains(n4) and
 218         s.neighbors("forlink").contains(n0)
 219       post-accum
 220         @@n_matchings += edge_23(n0, n1, n2, n3, n4, s)
 221       post-accum
 222         @@n_matchings += edge_24(n0, n1, n2, n3, n4, s);
 223
 224   return @@n_matchings;
 225 }

When I tried to add the subquery, here is what gsql complains:

Warning in query edge_22 (WARN-10): line 210, col 8
You are running queries in a cluster environment.
If query is running slow, you may try creating a distributed query by using the
"DISTRIBUTED" keyword
i.e. CREATE DISTRIBUTED QUERY query_name() { ... }
Warning in query edge_22 (WARN-10): line 211, col 8
You are running queries in a cluster environment.
If query is running slow, you may try creating a distributed query by using the
"DISTRIBUTED" keyword
i.e. CREATE DISTRIBUTED QUERY query_name() { ... }
Warning in query edge_22 (WARN-10): line 212, col 8
You are running queries in a cluster environment.
If query is running slow, you may try creating a distributed query by using the
"DISTRIBUTED" keyword
i.e. CREATE DISTRIBUTED QUERY query_name() { ... }
Warning in query edge_22 (WARN-10): line 213, col 8
You are running queries in a cluster environment.
If query is running slow, you may try creating a distributed query by using the
"DISTRIBUTED" keyword
i.e. CREATE DISTRIBUTED QUERY query_name() { ... }
Warning in query edge_22 (WARN-10): line 214, col 8
You are running queries in a cluster environment.
If query is running slow, you may try creating a distributed query by using the
"DISTRIBUTED" keyword
i.e. CREATE DISTRIBUTED QUERY query_name() { ... }
null
For more info, please check log at node 'm2': /home/tigergraph/tigergraph/log/gsql/log.ERROR
The query edge_22 cannot be added!

Here is the exception when I looked into log.ERROR on m2:

E@20210428 21:42:49.563 tigergraph|localhost:58264|00000000007 (Catalog.java:1247) java.lang.NullPointerException
java.lang.NullPointerException
        at com.tigergraph.engine.typechecker.VarType.a(VarType.java:1331)
        at com.tigergraph.engine.typechecker.VarType.a(VarType.java:1348)
        at com.tigergraph.engine.typechecker.VarType.a(VarType.java:1348)
        at com.tigergraph.engine.typechecker.VarType.a(VarType.java:1348)
        at com.tigergraph.engine.typechecker.VarType.a(VarType.java:1348)
        at com.tigergraph.engine.typechecker.VarType.a(VarType.java:1348)
        at com.tigergraph.engine.typechecker.VarType.a(VarType.java:1348)
        at com.tigergraph.engine.typechecker.VarType.a(VarType.java:1348)
        at com.tigergraph.engine.typechecker.VarType.a(VarType.java:1348)
        at com.tigergraph.engine.typechecker.VarType.a(VarType.java:1348)
        at com.tigergraph.engine.typechecker.VarType.a(VarType.java:1310)
        at com.tigergraph.engine.util.h.e(gsqlUtilBaseListener.java:197)
        at com.tigergraph.engine.util.h.aD(gsqlUtilBaseListener.java:181)
        at com.tigergraph.engine.semchecker.l.exitRhsIdent(SemChecker.java:804)
        at com.tigergraph.engine.parser.GSQLParser$RhsIdentContext.exitRule(GSQLParser.java:6007)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.exitRule(ParseTreeWalker.java:47)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:30)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
        at com.tigergraph.engine.codegen.p.a(GSQL2UDFCompiler.java:950)
        at com.tigergraph.schema.Catalog.a(Catalog.java:1178)
        at com.tigergraph.schema.handler.QueryBlockHandler.a(QueryBlockHandler.java:455)
        at com.tigergraph.schema.handler.QueryBlockHandler.a(QueryBlockHandler.java:195)
        at com.tigergraph.schema.handler.QueryBlockHandler.a(QueryBlockHandler.java:137)
        at com.tigergraph.schema.handler.FileHandler.a(FileHandler.java:47)
        at com.tigergraph.schema.handler.BaseHandler.handle(BaseHandler.java:150)
        at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:79)
        at sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:72)
        at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:82)
        at sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:675)
        at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:79)
        at sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:647)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

The problem seems to be related to the use of multiple post-accums, as the error is gone if I merge the two post-accums into one. But as described here, it should be allowed to use multiple post-accums. Is multiple post-accums only available in v2 syntax? I tried to change to v2 syntax, but I still get a NullPointerException which is different from the previous one.

E@20210428 22:02:44.620 tigergraph|localhost:43648|00000000012 (Catalog.java:1247) java.lang.NullPointerException
java.lang.NullPointerException
        at com.tigergraph.engine.typechecker.DataType.CompatibilityCheck(DataType.java:1293)
        at com.tigergraph.engine.typechecker.patterntypechecker.d.a(DataTypeAnnotationSet.java:740)
        at com.tigergraph.engine.typechecker.patterntypechecker.a.a(BottomUpTypeAnnotator.java:2554)
        at com.tigergraph.engine.typechecker.patterntypechecker.a.exitAllFuncAccess(BottomUpTypeAnnotator.java:1351)
        at com.tigergraph.engine.parser.GSQLParser$AllFuncAccessContext.exitRule(GSQLParser.java:11217)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.exitRule(ParseTreeWalker.java:47)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:30)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
        at com.tigergraph.engine.codegen.p.b(GSQL2UDFCompiler.java:288)
        at com.tigergraph.engine.codegen.p.a(GSQL2UDFCompiler.java:756)
        at com.tigergraph.schema.Catalog.a(Catalog.java:1178)
        at com.tigergraph.schema.handler.QueryBlockHandler.a(QueryBlockHandler.java:455)
        at com.tigergraph.schema.handler.QueryBlockHandler.a(QueryBlockHandler.java:195)
        at com.tigergraph.schema.handler.QueryBlockHandler.a(QueryBlockHandler.java:137)
        at com.tigergraph.schema.handler.FileHandler.a(FileHandler.java:47)
        at com.tigergraph.schema.handler.BaseHandler.handle(BaseHandler.java:150)
        at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:79)
        at sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:72)
        at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:82)
        at sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:675)
        at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:79)
        at sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:647)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

Yes, multiple POST-ACCUM clauses are only available in syntax V2.
For syntax V2, you would also need to remove the outer arrowhead in
-(revlink)-> instead having
-(revlink)- if the edge type is undirected or
-(revlink>)- if it is directed

For V1, it is optional to use the arrowhead; we recommend that you get used to not using it to be more consistent with V2.

Also, I am fairly certain that contains() is not part of the GSQL function library.
It is definitely not in our documentation.

So that could be another cause of errors.

Hi @Victor_Lee, thank you for your reply.

Yes, multiple POST-ACCUM clauses are only available in syntax V2.

I am pretty sure the reason for the first exception is indeed that I used multiple post-accume clauses under syntax V1.

For syntax V2, you would also need to remove the outer arrowhead

Yes, I changed the position of the arrow when I switched to syntax v2.

Also, I am fairly certain that contains() is not part of the GSQL function library.
It is definitely not in our documentation.

I at the end find that what I want to do in the above query can be actually achieved by Conjunctive Pattern Matching. After I replace the where caluse with conjunctive pattern matching, the second exception is gone, so I am sure that the second exception is due to the use of x.neighbors(y).contains(z).

Here is how I come up with the use of x.neighbors(y).contains(z) from the documents:

  1. x is a vertex alias, so I can use vertex functions on x, and neighbors() is one of the vertex functions I can use.
  2. The returned value of neighbors() is BagAccum<VERTEX>, which is a accumulator.
  3. I checked what member functions I can use on BagAccum<VERTEX> in here. I found that I can use contains() to find if a vertex is in a BagAccum<VERTEX>.

So … I think the use of x.neighbors(y).contains(z) should be legal. At least, that works under syntax v1.