tests/e2e/Services/Databases/Legacy/DatabasesBase.php (1)

357-359: Consider replacing fixed sleeps with SchemaPoll polling helpers

Now that SchemaPoll is mixed into this trait, these hard-coded sleep() calls (and similar ones elsewhere in this file) could be gradually replaced with the trait’s waitFor* helpers so tests wait on actual attribute/index readiness instead of time-based guesses. This would reduce flakiness and speed up runs when the worker is faster than the fixed delay.

tests/e2e/Services/Databases/TablesDB/DatabasesBase.php (1)

370-372: Consider replacing remaining sleep() calls with SchemaPoll wait helpers

Now that SchemaPoll is wired in, the fixed sleep() after column/index creation (and similar sleeps elsewhere in this trait) can be swapped for waitForAttribute / waitForAllAttributes / waitForIndex-style helpers to reduce flakiness and keep this suite consistent with the rest of the PR.

tests/e2e/Services/Databases/TablesDB/DatabasesCustomClientTest.php (1)

214-214: Consider replacing fixed delay with polling.

This fixed usleep(500 * 1000) is inconsistent with the PR's objective to remove database sleeps. Since table deletion is asynchronous, consider using a polling approach similar to the attribute waits, or verify that the subsequent 404 check (lines 217-222) adequately handles the async nature of deletion without needing this delay.

🔄 Suggested polling approach

If table deletion timing is critical, consider adding a helper method similar to waitForAttribute that polls for table deletion:

// Poll until table returns 404
$this->assertEventually(function () use ($databaseId) {
    $response = $this->client->call(Client::METHOD_GET, '/tablesdb/' . $databaseId . '/tables/permissionCheck', array_merge([
        'content-type' => 'application/json',
        'x-appwrite-project' => $this->getProject()['$id'],
        'x-appwrite-key' => $this->getProject()['apiKey']
    ]));
    $this->assertEquals(404, $response['headers']['status-code']);
    return true;
}, 5000, 100);

Alternatively, if the immediate 404 check works reliably without the sleep, the usleep could potentially be removed entirely.

tests/e2e/Services/Databases/TablesDB/DatabasesCustomServerTest.php (2)

1306-1317: Replace hand-rolled polling loops with assertEventually for consistency

Both deletion checks use manual microtime/usleep loops to wait for a 404, duplicating what assertEventually already does in SchemaPoll. Refactoring to assertEventually would reduce boilerplate and give clearer failure output on timeouts.

Example refactor using assertEventually

-        $start = microtime(true) * 1000;
-        while ((microtime(true) * 1000) - $start < 30000) {
-            $response = $this->client->call(Client::METHOD_GET, '/tablesdb/' . $databaseId . '/tables/' . $table2, array_merge([
-                'content-type' => 'application/json',
-                'x-appwrite-project' => $this->getProject()['$id'],
-                'x-appwrite-key' => $this->getProject()['apiKey'],
-            ]));
-            if ($response['headers']['status-code'] === 404) {
-                break;
-            }
-            usleep(100 * 1000);
-        }
+        $this->assertEventually(function () use ($databaseId, $table2) {
+            $response = $this->client->call(Client::METHOD_GET, '/tablesdb/' . $databaseId . '/tables/' . $table2, array_merge([
+                'content-type' => 'application/json',
+                'x-appwrite-project' => $this->getProject()['$id'],
+                'x-appwrite-key' => $this->getProject()['apiKey'],
+            ]));
+
+            $this->assertEquals(404, $response['headers']['status-code']);
+            return true;
+        }, 30000, 100);

A similar pattern can be applied in cleanupRelationshipTable() for /tablesdb/database1.

Also applies to: 3697-3710

---

4497-4497: Consider replacing remaining fixed usleep calls with polling

The two usleep(500 * 1000); waits around the bulk-update cache invalidation are small but still time-based heuristics. If these tests are still flaky on slow environments, you might want to replace them with an assertEventually check on whatever invariant you expect after the cache purge (e.g., row count or field values) instead of sleeping for a fixed duration.

Also applies to: 4523-4523

tests/e2e/Services/Databases/Legacy/DatabasesCustomServerTest.php (2)

3745-3766: Make database deletion polling fail explicitly on timeout

cleanupRelationshipCollection()’s manual polling loop exits quietly after 30s even if /databases/database1 never returns 404, which can leave residual state and make later tests fail in harder-to-diagnose ways. Adding an explicit failure after the loop would make such issues surface clearly.

💡 Minimal change to fail on timeout

         $this->client->call(Client::METHOD_DELETE, '/databases/database1', [
             'content-type' => 'application/json',
             'x-appwrite-project' => $this->getProject()['$id'],
             'x-appwrite-key' => $this->getProject()['apiKey']
         ]);
 
-        // Poll until database is deleted (returns 404)
+        // Poll until database is deleted (returns 404)
         $start = microtime(true) * 1000;
         $timeoutMs = 30000;
         while ((microtime(true) * 1000) - $start < $timeoutMs) {
             $response = $this->client->call(Client::METHOD_GET, '/databases/database1', [
                 'content-type' => 'application/json',
                 'x-appwrite-project' => $this->getProject()['$id'],
                 'x-appwrite-key' => $this->getProject()['apiKey']
             ]);
             if ($response['headers']['status-code'] === 404) {
                 return;
             }
             usleep(100 * 1000);
         }
+
+        $this->fail('Timed out waiting for database1 deletion');

---

4553-4553: Consider replacing fixed 500 ms cache sleeps with assertion-based polling

The two usleep(500 * 1000) calls still rely on hard-coded timing for cache purge, which may be tight on slower CI or busy DB nodes and can reintroduce flakiness. Since you already have assertEventually available, you could instead poll for the expected document state (e.g., updated number values) and drop these fixed sleeps.

Also applies to: 4579-4579

tests/e2e/Services/Databases/Legacy/DatabasesCustomClientTest.php (1)

214-225: Consider extracting collection deletion polling to SchemaPoll trait.

This manual polling loop is functional but inconsistent with the trait-based approach used for attributes and indexes. Extracting a waitForCollectionDeletion method to the SchemaPoll trait would improve code reusability and consistency across the test suite.

♻️ Example trait method to add to SchemaPoll.php

protected function waitForCollectionDeletion(
    string $databaseId,
    string $collectionId,
    int $timeoutMs = 30000,
    int $intervalMs = 100
): void {
    $config = $this->getSchemaApiConfig();
    
    $this->assertEventually(function () use ($config, $databaseId, $collectionId) {
        $response = $this->client->call(
            Client::METHOD_GET,
            $config['basePath'] . '/' . $databaseId . '/' . $config['collectionPath'] . '/' . $collectionId,
            array_merge([
                'content-type' => 'application/json',
                'x-appwrite-project' => $this->getProject()['$id'],
                'x-appwrite-key' => $this->getProject()['apiKey']
            ])
        );
        
        $this->assertEquals(404, $response['headers']['status-code']);
        return true;
    }, $timeoutMs, $intervalMs);
}

Then replace the manual loop with:

-$start = microtime(true) * 1000;
-while ((microtime(true) * 1000) - $start < 30000) {
-    $response = $this->client->call(Client::METHOD_GET, '/databases/' . $databaseId . '/collections/permissionCheck', array_merge([
-        'content-type' => 'application/json',
-        'x-appwrite-project' => $this->getProject()['$id'],
-        'x-appwrite-key' => $this->getProject()['apiKey']
-    ]));
-    if ($response['headers']['status-code'] === 404) {
-        break;
-    }
-    usleep(100 * 1000);
-}
+$this->waitForCollectionDeletion($databaseId, 'permissionCheck');

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro