Try bumping eventually very long

[ci]

Signed-off-by: Moritz Kiefer <[email protected]>

Author: cocreature

apps/app/src/test/scala/org/lfdecentralizedtrust/splice/integration/tests/RecordTimeToleranceTimeBasedIntegrationTest.scala

@@ -9,6 +9,7 @@ import com.digitalasset.canton.topology.admin.grpc.TopologyStoreId
 import com.digitalasset.canton.topology.store.TimeQuery
 
 import java.time.Duration
+import scala.concurrent.duration.*
 
 class RecordTimeToleranceTimeBasedIntegrationTest
     extends IntegrationTest
@@ -65,7 +66,7 @@ class RecordTimeToleranceTimeBasedIntegrationTest
       }
       // We go slightly above 48h as time is not actually completely still in simtime, the microseconds still advance.
       advanceTime(Duration.ofHours(49))
-      eventually() {
+      eventually(4.minutes) {
         sv1Backend.participantClient.topology.synchronizer_parameters
           .get_dynamic_synchronizer_parameters(synchronizerId)
           .preparationTimeRecordTimeTolerance shouldBe NonNegativeFiniteDuration.ofHours(24)

project/ignore-patterns/canton_log_simtime_extra.ignore.txt

@@ -34,6 +34,7 @@ Request failed for sequencer.*GrpcServiceUnavailable: UNAVAILABLE/Health-check s
 
 # TODO(#2668) Remove once Canton improves the log here.
 Request failed for.*Is the server running.*GrpcConnectionX
+Failed to acknowledge clean timestamp (usually because sequencer is down): ConnectionError(TransportError(Request failed for server-DefaultSequencer-0. Is the server running?
 
 # This kicks in when an interval is skipped which can easily be caused in simtime mode
 # by bumping the time by more than the reconciliation interval.