importccl: re-enable job control tests #31556
Conversation
|
This change is |
|
I guess this is still failing. Ugggggggh. Running more tests on my laptop. |
|
Updated with a real fix. PTAL. |
There was a problem hiding this comment.
Reviewable status:
complete! 0 of 0 LGTMs obtained
pkg/ccl/importccl/import_stmt_test.go, line 1536 at r1 (raw file):
srv := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { if r.Method == "GET" { // The following code correctly (I hope) handles both the case where, after
No need to leave the I hope in there. Either it does (in which case you're unlikely to ever remove the I hope) or it doesn't in which case another failure will occur and you'll work on another fix.
pkg/ccl/importccl/import_stmt_test.go, line 1548 at r1 (raw file):
for range allowResponse { } }()
Probably doesn't matter, but I think this more naturally belongs inside of the once.Do.
There was a problem hiding this comment.
Reviewable status:
pkg/ccl/importccl/import_stmt_test.go, line 1536 at r1 (raw file):
Previously, petermattis (Peter Mattis) wrote…
No need to leave the
I hopein there. Either it does (in which case you're unlikely to ever remove theI hope) or it doesn't in which case another failure will occur and you'll work on another fix.
Done.
pkg/ccl/importccl/import_stmt_test.go, line 1548 at r1 (raw file):
Previously, petermattis (Peter Mattis) wrote…
Probably doesn't matter, but I think this more naturally belongs inside of the
once.Do.
Done.
I tracked down the problem. It was that after the CANCEL JOB was issued, sometimes the 2nd stage of the IMPORT (the shuffle) would have started, and sometimes it wouldn't have. If it did not start then RunJob would block forever trying to send on the allowResponse chan. Fix this by making a draining go routine after the first block. Closes #24623 Closes #24658 Release note: None
|
bors r+ |
31556: importccl: re-enable job control tests r=mjibson a=mjibson I tracked down the problem. It was that after the CANCEL JOB was issued, sometimes the 2nd stage of the IMPORT (the shuffle) would have started, and sometimes it wouldn't have. If it did not start then RunJob would block forever trying to send on the allowResponse chan. Fix this by making a draining go routine after the first block. Closes #24623 Closes #24658 Release note: None 31627: storage: remove spurious call to maybeInlineSideloadedRaftCommand r=nvanbenschoten,benesch a=tschottdorf Entries are "thinned" only when passed to `r.append()` (i.e. written to disk) and they are always returned "fat" from `Entries()` (i.e. Raft's way to get entries from disk). Consequently Raft never sees thin entries and won't ask us to commit them. Touches #31618. Release note: None 31695: bitarray: don't allow FromEncodingParts to return invalid bit array r=knz a=benesch It is invalid for a bit array's lastBitsUsed field to be greater than 64. The FromEncodingParts function, however, would happily construct an invalid bitarray if given a too-large lastBitsUsed value. Teach the FromEncodingParts to return an error instead. This presented as a panic when attempting to pretty-print a key with a bitarray whose lastBitsUsed encoded value was 65. Such a key can be created when calling PrefixEnd on a key with a bitarray whose lastBitsUsed value is 64. By returning an error instead, the pretty-printing code will try again after calling UndoPrefixEnd and be able to print the key. Fix #31115. Release note: None 31697: partitionccl: deflake TestDropIndexWithZoneConfigCCL r=danhhz,eriktrinh a=benesch A particularly adversarial goroutine schedule can cause this test to observe the moment in time where the data is dropped but the zone config is not. Deflake by retrying the check for the dropped zone config until it succeeds (or times out). Fix #31678. Release note: None Co-authored-by: Matt Jibson <[email protected]> Co-authored-by: Tobias Schottdorf <[email protected]> Co-authored-by: Nikhil Benesch <[email protected]>
Build succeeded
|
I tracked down the problem. It was that after the CANCEL JOB was issued,
sometimes the 2nd stage of the IMPORT (the shuffle) would have started,
and sometimes it wouldn't have. If it did not start then RunJob would
block forever trying to send on the allowResponse chan. Fix this by
making a draining go routine after the first block.
Closes #24623
Closes #24658
Release note: None