largeUnary interop test flaky: wrong method name in stats check

[ericgribkoff]

org.junit.ComparisonFailure: method names match expected:<...testing.TestService/[Unary]Call> but was:<...testing.TestService/[StreamingOutput]Call>
	at org.junit.Assert.assertEquals(Assert.java:115)
	at io.grpc.testing.integration.AbstractInteropTest.checkStartTags(AbstractInteropTest.java:1916)
	at io.grpc.testing.integration.AbstractInteropTest.assertServerStatsTrace(AbstractInteropTest.java:1855)
	at io.grpc.testing.integration.AbstractInteropTest.assertStatsTrace(AbstractInteropTest.java:1779)
	at io.grpc.testing.integration.AbstractInteropTest.largeUnary(AbstractInteropTest.java:373)
	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.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.lang.Thread.run(Thread.java:748)

Seen here: https://kokoro2.corp.google.com/job/grpc/job/java/job/master/job/windows/job/presubmit/job/windows/386/ on PR #3776.

@zhangkun83 Any thoughts on this? My first thought was to blame my #3754 PR, but it looks like this is on the server side, and the server stream doesn't have to worry about multiple streams per call so it shouldn't be impacted even if there were a mistake in #3754.

[zhangkun83]

It's possible that a stats from a previous test leaks into the current test, because the server is shared among the tests. We mitigate this problem by trying until all tracer records are checked. How flaky is it? Does it always fail with the same error?