@@ -51,6 +51,7 @@ function waitFor(
5151
5252 const usingJestFakeTimers = jestFakeTimersAreEnabled ( )
5353 if ( usingJestFakeTimers ) {
54+ const { unstable_advanceTimersWrapper : advanceTimersWrapper } = getConfig ( )
5455 checkCallback ( )
5556 // this is a dangerous rule to disable because it could lead to an
5657 // infinite loop. However, eslint isn't smart enough to know that we're
@@ -71,7 +72,9 @@ function waitFor(
7172 // third party code that's setting up recursive timers so rapidly that
7273 // the user's timer's don't get a chance to resolve. So we'll advance
7374 // by an interval instead. (We have a test for this case).
74- jest . advanceTimersByTime ( interval )
75+ advanceTimersWrapper ( ( ) => {
76+ jest . advanceTimersByTime ( interval )
77+ } )
7578
7679 // It's really important that checkCallback is run *before* we flush
7780 // in-flight promises. To be honest, I'm not sure why, and I can't quite
@@ -84,9 +87,11 @@ function waitFor(
8487 // of parallelization so we're fine.
8588 // https://stackoverflow.com/a/59243586/971592
8689 // eslint-disable-next-line no-await-in-loop
87- await new Promise ( r => {
88- setTimeout ( r , 0 )
89- jest . advanceTimersByTime ( 0 )
90+ await advanceTimersWrapper ( async ( ) => {
91+ await new Promise ( r => {
92+ setTimeout ( r , 0 )
93+ jest . advanceTimersByTime ( 0 )
94+ } )
9095 } )
9196 }
9297 } else {
0 commit comments