Jenkins build is still unstable: Kafka » Kafka Branch Builder » trunk #2443

[Apache Jenkins Server]

See 

Jenkins build is unstable: Kafka » Kafka Branch Builder » trunk #2442

[Apache Jenkins Server]

See 

[jira] [Resolved] (KAFKA-15957) ConsistencyVectorIntegrationTest.shouldHaveSamePositionBoundActiveAndStandBy broken

[Matthias J. Sax (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-15957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthias J. Sax resolved KAFKA-15957.
-
Resolution: Fixed

> ConsistencyVectorIntegrationTest.shouldHaveSamePositionBoundActiveAndStandBy 
> broken
> ---
>
> Key: KAFKA-15957
> URL: https://issues.apache.org/jira/browse/KAFKA-15957
> Project: Kafka
>  Issue Type: Bug
>Reporter: Justine Olshan
>Assignee: Lucas Brutschy
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [DISCUSS] KIP-997 Support fetch(fromKey, toKey, from, to) to WindowRangeQuery and unify WindowKeyQuery and WindowRangeQuery

[Alieh Saeedi]

Thanks, Hanyu, for the KIP and all the updates.
I just do not understand the purpose of defining new time ranges
(`newTimeFrom`, `newTimeTo`). Why don't we simply re-use the existing time
range variables?

Bests,
Alieh

On Thu, Nov 30, 2023 at 8:34 PM Hanyu (Peter) Zheng
 wrote:

> new KIP link:
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-997%3A++update+WindowRangeQuery+and+unify+WindowKeyQuery+and+WindowRangeQuery
>
> On Wed, Nov 29, 2023 at 10:12 PM Hanyu (Peter) Zheng 
> wrote:
>
> > Thank you Bruno,
> > 1. Thank you for the notification. I have updated the ticket link
> > accordingly.
> > 2. Certainly, I'll update the KIP name. Should I initiate a new
> discussion
> > for it, because if I change the name, the link will change.
> > 3. Understood, I will add that to the KIP.
> > 4. I propose we accept both
> > `WindowRangeQuery.withAllKeys().fromTime(time1).toTime(time2)` and
> > `WindowRangeQuery.withKeyRange(key1,
> key2).fromTime(time1).toTime(time2)`,
> > while also reusing the existing `withKey` method.
> > 5. Following a discussion with Matthias, we've decided to defer the
> > implementation of order guarantees to a future KIP.
> >
> > Sincerely,
> > Hanyu
> >
> > On Wed, Nov 29, 2023 at 6:22 AM Bruno Cadonna 
> wrote:
> >
> >> Hi,
> >>
> >> Thanks for the updates!
> >>
> >>
> >> 1.
> >> Could you please link the correct ticket in the KIP?
> >>
> >> 2.
> >> Could you please adapt the motivation section and the title to the
> >> updated goal of the KIP? There is no fetch() or fetchAll() method in the
> >> query class.
> >>
> >> 3.
> >> Could you please add the "// newly added" comment to all parts that were
> >> newly added? That is methods lowerKeyBound() and upperKeyBound().
> >>
> >> 4.
> >> We should use a more fluent API as I proposed in my last e-mail:
> >>
> >> Here again
> >>
> >> WindowRangeQuery.withAllKeys().fromTime(time1).toTime(time2);
> >> WindowRangeQuery.withKey(key1).fromTime(time1).toTime(time2);
> >> WindowRangeQuery.withKeyRange(key1, key2).fromTime(time1).toTime(time2);
> >>
> >> 5.
> >> We should also consider the order of the results similar as we did in
> >> KIP-968. Alternatively, we do not guarantee any order and postpone the
> >> order guarantees to a future KIP.
> >>
> >>
> >> Best,
> >> Bruno
> >>
> >>
> >>
> >> On 11/17/23 3:11 AM, Matthias J. Sax wrote:
> >> > Thanks for the KIP.
> >> >
> >> > Given how `WindowRangeQuery` works right now, it's really time to
> >> > improve it.
> >> >
> >> >
> >> > 1) Agree. It's not clear what will be added right now. I think we
> >> should
> >> > deprecate existing `getKey()` w/o an actually replacement? For
> >> > `getFromKey` and `getToKey` we should actually be `lowerKeyBound()`
> and
> >> > `upperKeyBound()` to align to KIP-969?
> >> >
> >> > Also wondering if we should deprecate existing `withKey()` and
> >> > `withWindowStartRange`? `withKey` only works for SessionStores and
> >> > implements a single-key full-time-range query. Similarly,
> >> > `withWindowStartRange` only works for WindowedStore and implements an
> >> > all-key time-range query. Thus, both are rather special and it seems
> >> the
> >> > aim of this KIP is to generalize `WindowRangeQuery` to arbitrary
> >> > key-range/time-range queries?
> >> >
> >> > What raises one question about time-range semantics, given that we
> >> query
> >> > windows with different semantics.
> >> >
> >> >   - The current `WindowStore` semantics used for
> >> > `WindowRangeQuery#withWindowStartRange` is considering only the window
> >> > start time, ie, the window-start time must fall into the query
> >> > time-range to be returned.
> >> >
> >> >   - In contrast, `SessionStore` time ranges base on `findSession` use
> >> > earliest-session-end-time and latest-session-end-time and thus
> >> implement
> >> > an "window-bounds / search-time-range overlap query".
> >> >
> >> > Is there any concern about semantic differences? I would also be
> >> > possible to use the same semantics for both query types, and maybe
> even
> >> > let the user pick with semantics they want (let users chose might
> >> > actually be the best thing to do)? -- We can also do this
> >> incrementally,
> >> > and limit the scope of this KIP (or keep the full KIP scope but
> >> > implement it incrementally only)
> >> >
> >> > Btw: I think we should not add any ordering at this point, and
> >> > explicitly state that no ordering is guarantee whatsoever at this
> point.
> >> >
> >> >
> >> >
> >> > 2) Agreed. We should deprecate `getFromTime` and `getToTime` and add
> >> new
> >> > method `fromTime` and `toTime`.
> >> >
> >> >
> >> >
> >> > 3) About the API. If we move forward with general key-range/time-range
> >> I
> >> > agree that a more modular approach might be nice. Not sure right now,
> >> > what the best approach would be for this? Looking into KIP-969, we
> >> might
> >> > want to have:
> >> >
> >> >   - static withKeyRange
> >> >   - static withLowerKeyBound
> >> >   - static withUpperKeyBound
> 

[jira] [Resolved] (KAFKA-15966) Test failure - ClassCastException in ConsistencyVectorIntegrationTest.shouldHaveSamePositionBoundActiveAndStandBy

[Andrew Schofield (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-15966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Schofield resolved KAFKA-15966.
--
Resolution: Duplicate

Just fixed by https://github.com/apache/kafka/pull/14895

> Test failure - ClassCastException in 
> ConsistencyVectorIntegrationTest.shouldHaveSamePositionBoundActiveAndStandBy
> -
>
> Key: KAFKA-15966
> URL: https://issues.apache.org/jira/browse/KAFKA-15966
> Project: Kafka
>  Issue Type: Bug
>  Components: streams
>Affects Versions: 3.7.0
>Reporter: Andrew Schofield
>Priority: Major
>  Labels: test-failure
>
> Gradle Test Run :streams:test > Gradle Test Executor 3 > 
> ConsistencyVectorIntegrationTest > 
> shouldHaveSamePositionBoundActiveAndStandBy FAILED
> java.lang.ClassCastException: java.lang.Integer cannot be cast to 
> org.apache.kafka.streams.state.ValueAndTimestamp
> at 
> org.apache.kafka.streams.integration.ConsistencyVectorIntegrationTest.checkPosition(ConsistencyVectorIntegrationTest.java:169)
> at 
> org.apache.kafka.streams.integration.ConsistencyVectorIntegrationTest.shouldHaveSamePositionBoundActiveAndStandBy(ConsistencyVectorIntegrationTest.java:140)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (KAFKA-15953) Refactor polling delays

[Andrew Schofield (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-15953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Schofield resolved KAFKA-15953.
--
Resolution: Fixed

> Refactor polling delays
> ---
>
> Key: KAFKA-15953
> URL: https://issues.apache.org/jira/browse/KAFKA-15953
> Project: Kafka
>  Issue Type: Sub-task
>  Components: clients
>Affects Versions: 3.7.0
>Reporter: Andrew Schofield
>Assignee: Andrew Schofield
>Priority: Major
> Fix For: 3.7.0
>
>
> This is a follow-on tasks for 
> https://issues.apache.org/jira/browse/KAFKA-15890. The idea is to reduce the 
> interaction between the application thread and the request managers which was 
> introduced in that earlier JIRA's patch.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (KAFKA-15966) Test failure - ClassCastException in ConsistencyVectorIntegrationTest.shouldHaveSamePositionBoundActiveAndStandBy

[Andrew Schofield (Jira)]

Andrew Schofield created KAFKA-15966:


 Summary: Test failure - ClassCastException in 
ConsistencyVectorIntegrationTest.shouldHaveSamePositionBoundActiveAndStandBy
 Key: KAFKA-15966
 URL: https://issues.apache.org/jira/browse/KAFKA-15966
 Project: Kafka
  Issue Type: Bug
  Components: streams
Affects Versions: 3.7.0
Reporter: Andrew Schofield


Gradle Test Run :streams:test > Gradle Test Executor 3 > 
ConsistencyVectorIntegrationTest > shouldHaveSamePositionBoundActiveAndStandBy 
FAILED
java.lang.ClassCastException: java.lang.Integer cannot be cast to 
org.apache.kafka.streams.state.ValueAndTimestamp
at 
org.apache.kafka.streams.integration.ConsistencyVectorIntegrationTest.checkPosition(ConsistencyVectorIntegrationTest.java:169)
at 
org.apache.kafka.streams.integration.ConsistencyVectorIntegrationTest.shouldHaveSamePositionBoundActiveAndStandBy(ConsistencyVectorIntegrationTest.java:140)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (KAFKA-15965) Test failure: org.apache.kafka.common.requests.BrokerRegistrationRequestTest

[Apoorv Mittal (Jira)]

Apoorv Mittal created KAFKA-15965:
-

 Summary: Test failure: 
org.apache.kafka.common.requests.BrokerRegistrationRequestTest
 Key: KAFKA-15965
 URL: https://issues.apache.org/jira/browse/KAFKA-15965
 Project: Kafka
  Issue Type: Bug
Reporter: Apoorv Mittal


2 tests for versions 0 and 1 fails consistently.

Build: 
https://ci-builds.apache.org/blue/organizations/jenkins/Kafka%2Fkafka-pr/detail/PR-14767/15/tests/

 
{code:java}
org.opentest4j.AssertionFailedError: BrokerRegistrationRequestData(brokerId=0, 
clusterId='test', incarnationId=Xil73H5bSZ2vYTWUVlf07Q, listeners=[], 
features=[], rack='a', isMigratingZkBroker=false, logDirs=[], 
previousBrokerEpoch=1) ==> expected: <-1> but was: 
<1>Stacktraceorg.opentest4j.AssertionFailedError: 
BrokerRegistrationRequestData(brokerId=0, clusterId='test', 
incarnationId=Xil73H5bSZ2vYTWUVlf07Q, listeners=[], features=[], rack='a', 
isMigratingZkBroker=false, logDirs=[], previousBrokerEpoch=1) ==> expected: 
<-1> but was: <1>at 
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
   at 
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
   at 
app//org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)  at 
app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:166)  at 
app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:660)  at 
app//org.apache.kafka.common.requests.BrokerRegistrationRequestTest.testBasicBuild(BrokerRegistrationRequestTest.java:57)
at 
java.base@17.0.7/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)at 
java.base@17.0.7/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
  at 
java.base@17.0.7/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.base@17.0.7/java.lang.reflect.Method.invoke(Method.java:568)
at 
app//org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:728)
  at 
app//org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
   at 
app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
 at 
app//org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
at 
app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
  at 
app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestTemplateMethod(TimeoutExtension.java:94)
   at 
app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
at 
app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
 at 
app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at 
app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
   at 
app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
 {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (KAFKA-15963) Flaky test: testBrokerHeartbeatDuringMigration [3] 3.6-IV0 – org.apache.kafka.controller.QuorumControllerTest

[Apoorv Mittal (Jira)]

Apoorv Mittal created KAFKA-15963:
-

 Summary: Flaky test: testBrokerHeartbeatDuringMigration [3] 
3.6-IV0 – org.apache.kafka.controller.QuorumControllerTest
 Key: KAFKA-15963
 URL: https://issues.apache.org/jira/browse/KAFKA-15963
 Project: Kafka
  Issue Type: Bug
Reporter: Apoorv Mittal


PR build: 
[https://ci-builds.apache.org/blue/organizations/jenkins/Kafka%2Fkafka-pr/detail/PR-14767/15/tests/]

 
{code:java}
java.util.concurrent.ExecutionException: 
org.apache.kafka.common.errors.NotControllerException: No controller appears to 
be active.Stacktracejava.util.concurrent.ExecutionException: 
org.apache.kafka.common.errors.NotControllerException: No controller appears to 
be active.at 
java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:396)
   at 
java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2073)
at 
org.apache.kafka.controller.QuorumControllerTest.testBrokerHeartbeatDuringMigration(QuorumControllerTest.java:1725)
  at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)   at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
 at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.base/java.lang.reflect.Method.invoke(Method.java:568)   at 
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:728)
   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.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
  at 
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
 at 
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
   at 
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestTemplateMethod(TimeoutExtension.java:94)
at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
 at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
 {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (KAFKA-15964) Flaky test: testHighAvailabilityTaskAssignorLargeNumConsumers – org.apache.kafka.streams.processor.internals.StreamsAssignmentScaleTest

[Apoorv Mittal (Jira)]

Apoorv Mittal created KAFKA-15964:
-

 Summary: Flaky test: 
testHighAvailabilityTaskAssignorLargeNumConsumers – 
org.apache.kafka.streams.processor.internals.StreamsAssignmentScaleTest
 Key: KAFKA-15964
 URL: https://issues.apache.org/jira/browse/KAFKA-15964
 Project: Kafka
  Issue Type: Bug
Reporter: Apoorv Mittal


PR build: 
[https://ci-builds.apache.org/blue/organizations/jenkins/Kafka%2Fkafka-pr/detail/PR-14767/15/tests/]

 
{code:java}
java.lang.AssertionError: The first assignment took too long to complete at 
94250ms.Stacktracejava.lang.AssertionError: The first assignment took too long 
to complete at 94250ms.  at 
org.apache.kafka.streams.processor.internals.StreamsAssignmentScaleTest.completeLargeAssignment(StreamsAssignmentScaleTest.java:220)
 at 
org.apache.kafka.streams.processor.internals.StreamsAssignmentScaleTest.testHighAvailabilityTaskAssignorLargeNumConsumers(StreamsAssignmentScaleTest.java:85)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)  
 at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
 at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.base/java.lang.reflect.Method.invoke(Method.java:568)   at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
 at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
  at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
   at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:299)
   at 
org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:293)
 {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (KAFKA-15962) Flaky test: testAlterPartitionVersion2KeepWorkingWhenControllerDowngradeToPre28IBP() – kafka.controller.ControllerIntegrationTest

[Apoorv Mittal (Jira)]

Apoorv Mittal created KAFKA-15962:
-

 Summary: Flaky test: 
testAlterPartitionVersion2KeepWorkingWhenControllerDowngradeToPre28IBP() – 
kafka.controller.ControllerIntegrationTest
 Key: KAFKA-15962
 URL: https://issues.apache.org/jira/browse/KAFKA-15962
 Project: Kafka
  Issue Type: Bug
Reporter: Apoorv Mittal


PR build: 
https://ci-builds.apache.org/blue/organizations/jenkins/Kafka%2Fkafka-pr/detail/PR-14767/15/tests/

 
{code:java}
java.util.NoSuchElementException: key not found: 
0Stacktracejava.util.NoSuchElementException: key not found: 0  at 
scala.collection.MapOps.default(Map.scala:274)   at 
scala.collection.MapOps.default$(Map.scala:273)  at 
scala.collection.AbstractMap.default(Map.scala:405)  at 
scala.collection.mutable.HashMap.apply(HashMap.scala:440)at 
kafka.controller.ControllerIntegrationTest.testAlterPartitionVersion2KeepWorkingWhenControllerDowngradeToPre28IBP(ControllerIntegrationTest.scala:1031)
  at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)   at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
 at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.base/java.lang.reflect.Method.invoke(Method.java:568)   at 
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:728)
   at 
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
 {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (KAFKA-15961) Flaky test: testTopicIdPersistsThroughControllerRestart() – kafka.controller.ControllerIntegrationTest

[Apoorv Mittal (Jira)]

Apoorv Mittal created KAFKA-15961:
-

 Summary: Flaky test:  
testTopicIdPersistsThroughControllerRestart() – 
kafka.controller.ControllerIntegrationTest
 Key: KAFKA-15961
 URL: https://issues.apache.org/jira/browse/KAFKA-15961
 Project: Kafka
  Issue Type: Bug
Reporter: Apoorv Mittal


PR build: 
[https://ci-builds.apache.org/blue/organizations/jenkins/Kafka%2Fkafka-pr/detail/PR-14767/15/tests/]

 
{code:java}
java.util.NoSuchElementException: 
None.getStacktracejava.util.NoSuchElementException: None.get  at 
scala.None$.get(Option.scala:627)at scala.None$.get(Option.scala:626)at 
kafka.controller.ControllerIntegrationTest.testTopicIdPersistsThroughControllerRestart(ControllerIntegrationTest.scala:1684)
 at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)   at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
 at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.base/java.lang.reflect.Method.invoke(Method.java:568)   at 
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:728)
   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:156)
 at 
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
   at 
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
 at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
  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)
 {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (KAFKA-15960) Flaky test: testQuotaOverrideDelete(String).quorum=kraft – kafka.api.ClientIdQuotaTest

[Apoorv Mittal (Jira)]

Apoorv Mittal created KAFKA-15960:
-

 Summary: Flaky test: testQuotaOverrideDelete(String).quorum=kraft 
– kafka.api.ClientIdQuotaTest
 Key: KAFKA-15960
 URL: https://issues.apache.org/jira/browse/KAFKA-15960
 Project: Kafka
  Issue Type: Bug
Reporter: Apoorv Mittal


PR build: 
[https://ci-builds.apache.org/blue/organizations/jenkins/Kafka%2Fkafka-pr/detail/PR-14767/15/tests/]

 
{code:java}
rg.opentest4j.AssertionFailedError: Client with 
id=QuotasTestProducer-!@#$%^&*() should have been throttled, 0.0 ==> expected: 
 but was: Stacktraceorg.opentest4j.AssertionFailedError: Client 
with id=QuotasTestProducer-!@#$%^&*() should have been throttled, 0.0 ==> 
expected:  but was:  at 
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
   at 
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
   at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63) 
   at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36) at 
app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:210)at 
app//kafka.api.QuotaTestClients.verifyThrottleTimeRequestChannelMetric(BaseQuotaTest.scala:260)
  at 
app//kafka.api.QuotaTestClients.verifyProduceThrottle(BaseQuotaTest.scala:269)  
 at 
app//kafka.api.BaseQuotaTest.testQuotaOverrideDelete(BaseQuotaTest.scala:157)   
 at 
java.base@17.0.7/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)at 
java.base@17.0.7/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
  at 
java.base@17.0.7/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 {code}
 

 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)