Disable testcontainers reaper process

[kegsay]

It's implicated in terminating mitmproxy containers early, which then causes test failures.

First seen: matrix-org/matrix-rust-sdk@d2fecb6

✅ TestAliceBobEncryptionWorks (1.01s)
✅ TestAliceBobEncryptionWorks/{rust_hs1}|{rust_hs1} (1.01s)
✅ TestBackupWrongRecoveryKeyFails (2.13s)
✅ TestBackupWrongRecoveryKeyFails/{rust_hs1}|{rust_hs1} (2.13s)
✅ TestBobCanSeeButNotDecryptHistoryInPublicRoom (2.3s)
✅ TestBobCanSeeButNotDecryptHistoryInPublicRoom/{rust_hs1}|{rust_hs1} (2.3s)
✅ TestCanBackupKeys (2.43s)
✅ TestCanBackupKeys/{rust_hs1}|{rust_hs1} (2.43s)
✅ TestCanDecryptMessagesAfterInviteButBeforeJoin (1.13s)
✅ TestCanDecryptMessagesAfterInviteButBeforeJoin/{rust_hs1}|{rust_hs1} (1.13s)
❌ TestChangingDeviceAfterInviteReEncrypts (3.09s)
❌ TestChangingDeviceAfterInviteReEncrypts/{rust_hs1}|{rust_hs1} (3.09s)
❌ TestClientRetriesSendToDevice (30ms)
❌ TestClientRetriesSendToDevice/{rust_hs1}|{rust_hs1} (30ms)
✅ TestDelayedInviteResponse (19.48s)
✅ TestDelayedInviteResponse/rust (19.48s)
✅ TestExistingSessionCannotGetKeysForOfflineServer (4.56s)
✅ TestExistingSessionCannotGetKeysForOfflineServer/rust (4.56s)
✅ TestFailedDeviceKeyDownloadRetries (5.35s)
✅ TestFailedDeviceKeyDownloadRetries/rust (5.35s)
❌ TestFailedKeysClaimRetries (110ms)
❌ TestFailedKeysClaimRetries/rust (110ms)
❌ TestFailedOneTimeKeyUploadRetries (30ms)
❌ TestFailedOneTimeKeyUploadRetries/rust (30ms)
❌ TestFallbackKeyIsUsedIfOneTimeKeysRunOut (140ms)
❌ TestFallbackKeyIsUsedIfOneTimeKeysRunOut/{rust_hs1}|{rust_hs1} (140ms)
✅ TestNewUserCannotGetKeysForOfflineServer (48.11s)
✅ TestNewUserCannotGetKeysForOfflineServer/rust (48.11s)
✅ TestOnNewDeviceBobCanSeeButNotDecryptHistoryInPublicRoom (5.71s)
✅ TestOnNewDeviceBobCanSeeButNotDecryptHistoryInPublicRoom/{rust_hs1}|{rust_hs1} (5.71s)
✅ TestOnRejoinBobCanSeeButNotDecryptHistoryInPublicRoom (2.4s)
✅ TestOnRejoinBobCanSeeButNotDecryptHistoryInPublicRoom/{rust_hs1}|{rust_hs1} (2.4s)
❌ TestRoomKeyIsCycledAfterEnoughMessages (30ms)
❌ TestRoomKeyIsCycledAfterEnoughMessages/{rust_hs1}|{rust_hs1} (30ms)
❌ TestRoomKeyIsCycledAfterEnoughTime (30ms)
❌ TestRoomKeyIsCycledAfterEnoughTime/{rust_hs1}|{rust_hs1} (30ms)
❌ TestRoomKeyIsCycledOnDeviceLogout (30ms)
❌ TestRoomKeyIsCycledOnDeviceLogout/{rust_hs1}|{rust_hs1} (30ms)
❌ TestRoomKeyIsCycledOnMemberLeaving (110ms)
❌ TestRoomKeyIsCycledOnMemberLeaving/{rust_hs1}|{rust_hs1} (110ms)
❌ TestRoomKeyIsNotCycled (30ms)
❌ TestRoomKeyIsNotCycled/{rust_hs1}|{rust_hs1} (30ms)
❌ TestRoomKeyIsNotCycledOnClientRestart (30ms)
❌ TestRoomKeyIsNotCycledOnClientRestart/rust (30ms)
❌ TestSigkillBeforeKeysUploadResponse (30ms)
❌ TestSigkillBeforeKeysUploadResponse/rust (30ms)
❌ TestToDeviceMessagesAreBatched (10ms)
❌ TestToDeviceMessagesAreBatched/rust (10ms)
✅ TestToDeviceMessagesAreProcessedInOrder (0s)
🚧 TestToDeviceMessagesAreProcessedInOrder/rust (0s)
❌ TestToDeviceMessagesArentLostWhenKeysQueryFails (30ms)
❌ TestToDeviceMessagesArentLostWhenKeysQueryFails/rust (30ms)
❌ TestUnprocessedToDeviceMessagesArentLostOnRestart (30ms)
❌ TestUnprocessedToDeviceMessagesArentLostOnRestart/rust (30ms)
✅ TestVerificationSAS (0s)
🚧 TestVerificationSAS/{rust_hs1}|{rust_hs1} (0s)

Note the rust package tests all pass:

✅ TestMultiprocessInitialE2EESyncDoesntDropDeviceListUpdates (9.51s)
🚧 TestMultiprocessNSE (0s)
✅ TestMultiprocessNSEBackupKeyMacError (8.19s)
✅ TestMultiprocessNSEOlmSessionWedge (9.23s)
✅ TestNSEReceive (28.04s)
✅ TestNSEReceiveForMessageWithManyUnread (8.38s)
✅ TestNSEReceiveForNonPreKeyMessage (5.43s)
✅ TestNSEReceiveForOldMessage (10.55s)
✅ TestNotificationClientDupeOTKUpload (9.14s)

Working theory:

• tests run in parallel
• when the rust package tests finish, mitmproxy is incorrectly killed
• ..causing the rest of the main tests to fail.

Complement does its own cleanup based on namespaces, which is different for each package, see:

complement-crypto/tests/rust/main_test.go

Line 18 in fdeb52c

instance.TestMain(m, "rust")

vs

complement-crypto/tests/main_test.go

Line 18 in fdeb52c

instance.TestMain(m, "crypto")

So I don't think this is Complement nuking the other package's mitmproxy.

[andybalaam]

Seems good to me. Worst case, we leave containers around for too long, but as long as we don't run out of memory that doesn't do any harm.