Skip to content
This repository was archived by the owner on Sep 26, 2023. It is now read-only.

BatcherImplTest.testThrottlingBlocking still flaky  #1615

Closed
Closed
BatcherImplTest.testThrottlingBlocking still flaky #1615
Assignees
diegomarquezp
Labels
priority: p3Desirable enhancement or fix. May not be included in next release.type: processA process-related concern. May include testing, release, or the like.

Description

@chanseokoh
chanseokoh
opened on Jan 28, 2022

The test is known to be flaky. So far, we did #1589 and #1600. (However, although it may just be me, I feel this became less flaky.)

Unfortunately, this failed again in #1613. The bright side of it is that we have a different error. Hopefully this reveals more information.

com.google.api.gax.batching.BatcherImplTest > testThrottlingBlocking FAILED
    org.mockito.exceptions.base.MockitoException: 
    No argument value was captured!
    You might have forgotten to use argument.capture() in verify()...
    ...or you used capture() in stubbing but stubbed method was not called.
    Be aware that it is recommended to use capture() only with verify()

    Examples of correct argument capturing:
        ArgumentCaptor<Person> argument = ArgumentCaptor.forClass(Person.class);
        verify(mock).doSomething(argument.capture());
        assertEquals("John", argument.getValue().getName());
        at com.google.api.gax.batching.BatcherImplTest.testThrottlingBlocking(BatcherImplTest.java:895)

Activity

  1. chanseokoh
    added
    type: processA process-related concern. May include testing, release, or the like.
    on Jan 28, 2022

  2. meltsufin commented on Jan 28, 2022

    @meltsufin
    meltsufin
    on Jan 28, 2022
    Contributor

    I've noticed it flaking again too. I'm at a loss here. I welcome another pair of eyes on this to try to fix it once and for all.

  3. vam-google commented on Jan 31, 2022

    @vam-google
    vam-google
    on Jan 31, 2022
    Contributor

    Was the previous fix done by increasing timeout somethign from 10 ms to 50 ms? That could be just not enough difference. In many of our tests we use timeout as high as 20 sec, so maybe try just increasing it to something like 1sec. Or maybe this is the indicator of the logic itself having flaws. (btw, I've bee noticing flakiness myself too).

  4. vam-google
    added
    priority: p3Desirable enhancement or fix. May not be included in next release.
    on Jan 31, 2022

  5. meltsufin commented on Jan 31, 2022

    @meltsufin
    meltsufin
    on Jan 31, 2022
    Contributor

    It wasn't just the timeout. I thought the test was actually written is such a way that it wasn't testing what was intended. I thought I fixed it, but there still seems to be some kind indeterminism happening with the threads.

  6. diegomarquezp
    self-assigned this
    on Aug 15, 2022

  7. meltsufin commented on Oct 26, 2022

    @meltsufin
    meltsufin
    on Oct 26, 2022
    Contributor

    Re-open if it's still flaky after #1775.

  8. meltsufin
    closed this as completedon Oct 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

priority: p3Desirable enhancement or fix. May not be included in next release.type: processA process-related concern. May include testing, release, or the like.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions