kv/kvnemesis: TestKVNemesisSingleNode_ReproposalChaos failed #107860
Assignees
Labels
A-kv-transactions
Relating to MVCC and the transactional model.
branch-master
Failures and bugs on the master branch.
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
C-test-failure
Broken test (automatically or manually discovered).
O-robot
Originated from a bot.
T-kv
KV Team
Milestone
Comments
cockroach-teamcity
added
branch-master
|
@AlexTalks assigning you to this, because I think this can be explained by #103817. We could stress this test before and after your proposed fix to get a feel for whether the problem persists. |
pav-kv
added
C-bug
|
kv/kvnemesis.TestKVNemesisSingleNode_ReproposalChaos failed with artifacts on master @ 8d2d2bf47cb3da1c27baa140a5afb5d28a5ed8f6: Parameters: |
|
I haven't been able to reproduce this yet despite ~150k runs in stress. Even tried stressing with the deadlock detector enabled since I saw one of the failures had Also, I'm not sure why there are no artifacts here -- @cockroachdb/dev-inf? It seems too early for them to have been cleaned up, which is especially unfortunate because the repro steps introduced by @tbg are not available. 😢 |
|
I noticed in the TeamCity config that the test was run with |
|
kv/kvnemesis.TestKVNemesisSingleNode_ReproposalChaos failed with artifacts on master @ e0de1f12d4f496fc7e4050a33e96f8c635c7a27c: Fatal error: Stack: Log preceding fatal error
Parameters: |
|
kv/kvnemesis.TestKVNemesisSingleNode_ReproposalChaos failed with artifacts on master @ a900aa218054812b782c0b3d130b25296c0d14e3: Parameters: |
|
kv/kvnemesis.TestKVNemesisSingleNode_ReproposalChaos failed with artifacts on master @ a900aa218054812b782c0b3d130b25296c0d14e3: Parameters: |
|
kv/kvnemesis.TestKVNemesisSingleNode_ReproposalChaos failed with artifacts on master @ ee2b0cc7c8c24a4c9d4a32514e1e917b5f139838: |
craig bot
pushed a commit
that referenced
this issue
Aug 28, 2023
109186: pkg/util/log: flush buffered network sinks on panic r=knz a=abarganier Previously, our crash reporter system would flush file log sinks as part of the process to handle a panic. This was an incomplete process, since buffered network sinks were not included in part of this flush process. This means that many times, panic logs would not make it to the network target, leading to a loss in observability. This patch introduces `log.FlushAllSync()`, which flushes both file and buffered network log sinks. It then updates the crash reporter to call into this, instead of just flushing file log sinks. `FlushAllSync()` contains timeout logic to prevent the process from completing if one of the underlying child sinks that a bufferedSink wraps becomes unavailable/hangs on its `output()` call. We originally attempted to fix this in #101562, but a bug in the bufferedSink code led us to roll back those changes. The bug in the bufferedSink code has since been fixed (#108928), so we can safely introduce this logic again. Release note: none Fixes: #106345 109578: rpc: increase gRPC server timeout from 1x to 2x NetworkTimeout r=andrewbaptist a=erikgrinaker This is intended as a conservative backport that changes as little as possible. For 23.2, we should restructure these settings a bit, possibly by removing NetworkTimeout and using independent timeouts for each component/parameter, since they have unique considerations (e.g. whether they are enforced above the Go runtime or by the OS, to what extent they are subject to RPC head-of-line blocking, etc). --- This patch increases the gRPC server timeout from 1x to 2x NetworkTimeout. This timeout determines how long the server will wait for a TCP send to receive a TCP ack before automatically closing the connection. gRPC enforces this via the OS TCP stack by setting TCP_USER_TIMEOUT on the network socket. While NetworkTimeout should be sufficient here, we have seen instances where this is affected by node load or other factors, so we set it to 2x NetworkTimeout to avoid spurious closed connections. An aggressive timeout is not particularly beneficial here, because the client-side timeout (in our case the CRDB RPC heartbeat) is what matters for recovery time following network or node outages -- the server side doesn't really care if the connection remains open for a bit longer. Touches #109317. Epic: none Release note (ops change): The default gRPC server-side send timeout has been increased from 2 seconds to 4 seconds (1x to 2x of COCKROACH_NETWORK_TIMEOUT), to avoid spurious connection failures in certain scenarios. This can be controlled via the new environment variable COCKROACH_RPC_SERVER_TIMEOUT. 109610: kv: remove assertions around non-txn'al locking reqs r=nvanbenschoten a=nvanbenschoten Closes #107860. Closes #109222. Closes #109581. Closes #109582. We might want to re-introduce these assertions in the future and reject these requests higher up the stack. For now, just remove them to deflake tests. Release note: None Co-authored-by: Alex Barganier <[email protected]> Co-authored-by: Erik Grinaker <[email protected]> Co-authored-by: Nathan VanBenschoten <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
kv/kvnemesis.TestKVNemesisSingleNode_ReproposalChaos failed with artifacts on master @ f295bd861a3a427652b19c2254d2401ebb4a3c8e:
Parameters:
TAGS=bazel,gss,stress=trueHelp
See also: How To Investigate a Go Test Failure (internal)
This test on roachdash | Improve this report!
Jira issue: CRDB-30226
The text was updated successfully, but these errors were encountered: