[jira] [Created] (CALCITE-5836) Implement Rel2Sql for MERGE
Gregory Hart created CALCITE-5836: - Summary: Implement Rel2Sql for MERGE Key: CALCITE-5836 URL: https://issues.apache.org/jira/browse/CALCITE-5836 Project: Calcite Issue Type: Improvement Components: core Reporter: Gregory Hart Assignee: Gregory Hart Add support for MERGE operations in RelToSqlConverter.visit(TableModify). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5494) Time zone tests in DateTimeUtilsTest should pass in Europe/London
Gregory Hart created CALCITE-5494:
-
Summary: Time zone tests in DateTimeUtilsTest should pass in
Europe/London
Key: CALCITE-5494
URL: https://issues.apache.org/jira/browse/CALCITE-5494
Project: Calcite
Issue Type: Bug
Components: avatica
Reporter: Gregory Hart
Assignee: Gregory Hart
The {{DateTimeUtilsTest.testSqlDateToUnixDateWithCustomCalendar}} test fails in
the Europe/London time zone. The issue is due to the use of
{{TimeZone.setRawOffset(int)}} which expects the provided value to be the
offset from GMT, but the test provides the offset from UTC.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5493) Time zone tests in SqlFunctions should pass in Europe/London
Gregory Hart created CALCITE-5493:
-
Summary: Time zone tests in SqlFunctions should pass in
Europe/London
Key: CALCITE-5493
URL: https://issues.apache.org/jira/browse/CALCITE-5493
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Gregory Hart
Assignee: Gregory Hart
The {{SqlFunctionsTest.testToIntWithTimeZone}} test fails in the Europe/London
time zone. The issue is due to the use of {{TimeZone.setRawOffset(int)}} which
expects the provided value to be the offset from GMT, but the test provides the
offset from UTC.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5443) Reset update count when checking for more results
Gregory Hart created CALCITE-5443:
-
Summary: Reset update count when checking for more results
Key: CALCITE-5443
URL: https://issues.apache.org/jira/browse/CALCITE-5443
Project: Calcite
Issue Type: Bug
Components: avatica
Reporter: Gregory Hart
Assignee: Gregory Hart
The JavaDoc for {{java.sql.Statement#getMoreResults(int)}} says there are no
more results when the following is true:
{code:java}
// stmt is a Statement object ((stmt.getMoreResults(current) == false) &&
(stmt.getUpdateCount() == -1)) {code}
In {{{}AvaticaStatement{}}}, {{getMoreResults(int)}} always returns {{false}}
but does not reset the {{{}updateCount{}}}. This could result in an infinite
loop in the JDBC client because the return value is indicating there are
additional results when there are actually none.
*Steps to reproduce:*
# Execute an INSERT query by calling Statement#execute(String). Verify that
the return value is false indicating it is an update count.
# Call Statement#getMoreResults(). Verify that the return value is false
indicating it is an update count or there are no more results.
# Call Statement#getUpdateCount().
*Expected results:*
The call to getUpdateCount() returns -1 indicating there are no more results.
*Actual results:*
The call to getUpdateCount() returns the update count for the INSERT query,
which should only have one result.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5414) Use DateTimeUtils to correctly convert between java.sql types and unix timestamps
Gregory Hart created CALCITE-5414: - Summary: Use DateTimeUtils to correctly convert between java.sql types and unix timestamps Key: CALCITE-5414 URL: https://issues.apache.org/jira/browse/CALCITE-5414 Project: Calcite Issue Type: Bug Components: core Reporter: Gregory Hart Assignee: Gregory Hart Converting java.sql types to unix timestamps requires extra steps to also convert to the correct calendar. Unix timestamps should follow the proleptic Gregorian calendar as defined by ISO-8601. Java uses the standard Gregorian calendar for java.sql types and switches to the Julian calendar for dates before the Gregorian shift. The DateTimeUtils class in Avatica correctly handles the calendar conversions. Calcite should use those methods since its own methods do not currently convert between calendars. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5161) NPE when inserting a null value into a decimal column
Gregory Hart created CALCITE-5161:
-
Summary: NPE when inserting a null value into a decimal column
Key: CALCITE-5161
URL: https://issues.apache.org/jira/browse/CALCITE-5161
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.30.0
Reporter: Gregory Hart
A NullPointerException is thrown when inserting a NULL value into a DECIMAL
column. My guess is that there's a missing check somewhere to return
RexBuilder#constantNull instead of creating a new RexLiteral with a null value.
*Steps to reproduce:*
insert into "foodmart"."promotion" values (666, 666, 'Test', NULL, NULL, NULL,
NULL)
*Expected results:*
The row is inserted.
*Actual results:*
{noformat}
Error while executing SQL "insert into "foodmart"."promotion" values (666, 666,
'Test', NULL, NULL, NULL, NULL)": Unable to implement
JdbcToEnumerableConverter: rowcount = 1.0, cumulative cost =
{1.2002 rows, 1.1 cpu, 0.0 io}, id = 13996
JdbcTableModify(table=[[foodmart, promotion]], operation=[INSERT],
flattened=[false]): rowcount = 1.0, cumulative cost = {1.1 rows, 1.0 cpu, 0.0
io}, id = 13994
JdbcValues(tuples=[[{ 666, 666, 'Test', null, null, null, null }]]):
rowcount = 1.0, cumulative cost = {1.0 rows, 1.0 cpu, 0.0 io}, id =
13982java.sql.SQLException: Error while executing SQL "insert into
"foodmart"."promotion" values (666, 666, 'Test', NULL, NULL, NULL, NULL)":
Unable to implement JdbcToEnumerableConverter: rowcount = 1.0, cumulative cost
= {1.2002 rows, 1.1 cpu, 0.0 io}, id = 13996
JdbcTableModify(table=[[foodmart, promotion]], operation=[INSERT],
flattened=[false]): rowcount = 1.0, cumulative cost = {1.1 rows, 1.0 cpu, 0.0
io}, id = 13994
JdbcValues(tuples=[[{ 666, 666, 'Test', null, null, null, null }]]):
rowcount = 1.0, cumulative cost = {1.0 rows, 1.0 cpu, 0.0 io}, id = 13982 at
org.apache.calcite.avatica.Helper.createException(Helper.java:56)
at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
at
org.apache.calcite.avatica.AvaticaStatement.executeLargeUpdate(AvaticaStatement.java:246)
at
org.apache.calcite.avatica.AvaticaStatement.executeUpdate(AvaticaStatement.java:240)
at org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:541)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.lambda$updates$0(CalciteAssert.java:1438)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.withConnection(CalciteAssert.java:1384)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.updates(CalciteAssert.java:1437)
at
org.apache.calcite.test.JdbcAdapterTest.testInsertNull(PtyJdbcAdapterTest.java:26)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:725)
at
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
at
org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:214)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
[jira] [Created] (CALCITE-5152) Unable to insert bytes using PreparedStatement
Gregory Hart created CALCITE-5152:
-
Summary: Unable to insert bytes using PreparedStatement
Key: CALCITE-5152
URL: https://issues.apache.org/jira/browse/CALCITE-5152
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.30.0
Reporter: Gregory Hart
When inserting a byte[] using a PreparedStatement and a JDBC schema,
ResultSetEnumerable passes Avatica's ByteString to the underlying JDBC
connection instead of converting it to byte[].
*Steps to reproduce:*
# Create a connection to the database (I used SQL Server 2019):
{code:java}
Properties info = new Properties();
info.setProperty("conformance", "sql_server_2008");
info.setProperty("lex", "sql_server");
info.setProperty("schemaType", "JDBC");
info.setProperty("schema.jdbcUrl",
"jdbc:sqlserver://localhost;databaseName=foodmart;trustServerCertificate=true");
info.setProperty("schema.jdbcUser", "foodmart");
info.setProperty("schema.jdbcPassword", "foodmart");
Connection c = DriverManager.getConnection("jdbc:calcite:", info);
{code}
# Create a table: CREATE TABLE test (value VARBINARY(255));
# Insert a byte[] into the database:
{code:java}
PreparedStatement insert = c.prepareStatement("INSERT INTO test VALUES (?)");
insert.setBytes(1, "Hello, world!".getBytes(StandardCharsets.UTF_8));
insert.execute(); {code}
*Expected result:*
The row is inserted.
*Actual result:*
{code:java}
java.sql.SQLException: While executing SQL [INSERT INTO "test" ("value")
(SELECT ? AS "value"
FROM (VALUES (0)) AS "t" ("ZERO"))] on JDBC sub-schema
at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
at
org.apache.calcite.avatica.AvaticaConnection.executeQueryInternal(AvaticaConnection.java:556)
at
org.apache.calcite.avatica.AvaticaPreparedStatement.execute(AvaticaPreparedStatement.java:239)
at com.mycompany.test.Test.test3(Test.java:163)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:725)
at
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
at
org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:214)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:210)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:135)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:66)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at
[jira] [Created] (CALCITE-5121) Rethrow RuntimeException as SQLException in Driver#onConnectionInit
Gregory Hart created CALCITE-5121:
-
Summary: Rethrow RuntimeException as SQLException in
Driver#onConnectionInit
Key: CALCITE-5121
URL: https://issues.apache.org/jira/browse/CALCITE-5121
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.30.0
Reporter: Gregory Hart
The documentation for org.apache.calcite.avatica.Handler#onConnectionInit
states that a SQLException should be thrown "on error". However, the
implementation of onConnectInit in org.apache.calcite.jdbc.Driver allows for
other types of exceptions to be thrown. This also breaks the documentation
contract for java.sql.Driver#connect since a RuntimeException could be throw
instead of the expected SQLException.
*Steps to reproduce:*
DriverManager.getConnection("jdbc:calcite:schemaType=JDBC;schema.jdbcUrl=jdbc:invalid:");
*Expected result:*
A SQLException is thrown
*Actual result:*
A RuntimeException is thrown
{code:java}
java.lang.RuntimeException: Error instantiating JsonCustomSchema(name=adhoc)
at org.apache.calcite.model.ModelHandler.visit(ModelHandler.java:277)
at
org.apache.calcite.model.JsonCustomSchema.accept(JsonCustomSchema.java:66)
at org.apache.calcite.model.ModelHandler.visit(ModelHandler.java:200)
at org.apache.calcite.model.ModelHandler.(ModelHandler.java:106)
at org.apache.calcite.jdbc.Driver$1.onConnectionInit(Driver.java:101)
at
org.apache.calcite.avatica.UnregisteredDriver.connect(UnregisteredDriver.java:139)
at java.sql.DriverManager.getConnection(DriverManager.java:664)
at java.sql.DriverManager.getConnection(DriverManager.java:270){code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (CALCITE-5120) Throw SQLException from UnregisteredDriver#connect if url is null
Gregory Hart created CALCITE-5120:
-
Summary: Throw SQLException from UnregisteredDriver#connect if url
is null
Key: CALCITE-5120
URL: https://issues.apache.org/jira/browse/CALCITE-5120
Project: Calcite
Issue Type: Bug
Components: avatica
Affects Versions: avatica-1.20.0
Reporter: Gregory Hart
The documentation for java.sql.Driver#connect states that a SQLException should
be thrown "if a database access error occurs or the url is null." However,
UnregisteredDriver throws a NullPointerException instead.
*Steps to reproduce:*
new org.apache.calcite.avatica.remote.Driver().connect(null, new Properties());
*Expected result:*
A SQLException is thrown
*Actual result:*
A NullPointerException is thrown
{noformat}
java.lang.NullPointerException
at
org.apache.calcite.avatica.UnregisteredDriver.acceptsURL(UnregisteredDriver.java:144)
at
org.apache.calcite.avatica.UnregisteredDriver.connect(UnregisteredDriver.java:130){noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (CALCITE-5088) Generated model should escape backslashes
Gregory Hart created CALCITE-5088:
-
Summary: Generated model should escape backslashes
Key: CALCITE-5088
URL: https://issues.apache.org/jira/browse/CALCITE-5088
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.28.0
Reporter: Gregory Hart
When a model is generated (because one is not provided in the JDBC URL), the
generated JSON does not properly escape backslashes.
Example in pseudo-code:
{code:java}
Properties info = new Properties();
info.setProperty("schema.jdbcUrl", "jdbc:mssql://host\\THEDB:1443");
DriverManager.getConnection("jdbc:calcite:", info);
{code}
Expected result:
The connection is opened successfully.
Actual result:
com.fasterxml.jackson.core.JsonParseException: Unrecognized character escape
'T' (code 84)
at [Source: (String)"{
...
"jdbcUrl": "jdbc:mssql://host\THEDB:1443"
...
at org.apache.calcite.model.ModelHandler.(ModelHandler.java:101)
at org.apache.calcite.jdbc.Driver$1.onConnectionInit(Driver.java:101)
Possible fix:
Add the following to
org.apache.calcite.util.JsonBuilder.append(JsonBuilder.java:95). This will fix
backslashes but there may be other characters that need to be escaped too.
{code:java}
.replace("\\", "")
{code}
[https://github.com/apache/calcite/blob/calcite-1.28.0/core/src/main/java/org/apache/calcite/util/JsonBuilder.java#L95]
It looks like it's being called by
org.apache.calcite.jdbc.Driver$1.model(Driver.java:153).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (CALCITE-5027) Incorrect format for timestamp literals
Gregory Hart created CALCITE-5027: - Summary: Incorrect format for timestamp literals Key: CALCITE-5027 URL: https://issues.apache.org/jira/browse/CALCITE-5027 Project: Calcite Issue Type: Bug Components: core Reporter: Gregory Hart The SqlDialect#quoteTimestampLiteral method uses the wrong format for standard SQL. Instead of "day of month" it uses "day of year", and instead of seconds is uses milliseconds. To fix this method, the format should be changed to: -MM-dd HH:mm:ss -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CALCITE-4892) Conversion from String in cursor accessors
Gregory Hart created CALCITE-4892: - Summary: Conversion from String in cursor accessors Key: CALCITE-4892 URL: https://issues.apache.org/jira/browse/CALCITE-4892 Project: Calcite Issue Type: Improvement Components: core Reporter: Gregory Hart Numeric accessors (such as LongAccessor) of the AbstractCursor class could automatically convert strings to the appropriate numeric type. Also, I looked to see if I could instead easily provide my own accessor implementations in Calcite, but the cursor implementation is hardcoded in CalciteResultSet and is not easy to override. An example where this would be useful is when using the JDBC adapter with PostgreSQL and Hibernate. Hibernate is expecting this conversion to happen in the driver and fails when Calcite throws an exception: cannot convert to long. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CALCITE-4878) Calling a stored procedure is unsupported
Gregory Hart created CALCITE-4878:
-
Summary: Calling a stored procedure is unsupported
Key: CALCITE-4878
URL: https://issues.apache.org/jira/browse/CALCITE-4878
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.28.0
Reporter: Gregory Hart
The node type for "CALL FN()" is not defined after validation. This appears to
be caused in part by the call being rewritten to a SELECT query. I tested as
far back as Calcite v1.5 and received the same exception.
*Expected results:*
The "CALL FN()" query is converted to "SELECT FN() FROM VOID(0)" and executes
successfully.
*Actual results:*
{code:java}
Error while executing SQL "call myfn('Hello')": class
org.apache.calcite.sql.SqlBasicCall: CALL `MYFN`('Hello')
java.sql.SQLException: Error while executing SQL "call myfn('Hello')": class
org.apache.calcite.sql.SqlBasicCall: CALL `MYFN`('Hello')
at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
at
org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
at
org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:542)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.lambda$ensurePlan$9(CalciteAssert.java:1793)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.withConnection(CalciteAssert.java:1501)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.ensurePlan(CalciteAssert.java:1792)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.planContains(CalciteAssert.java:1767)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.planHasSql(CalciteAssert.java:1784)
at com.company.Test.test(Test.java:88)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:725)
at
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
at
org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:214)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:210)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:135)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:66)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at
org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at
