app/config/events.php (3)

112-117: Optional: keep key order stable to minimize churn

Unless there’s a strong reason to reorder, consider appending the new key without moving existing ones. This keeps diffs smaller and stays closer to existing conventions across this file.

Apply this diff to place 'upsert' after 'delete' while keeping semantics unchanged:

-                'upsert' => [
-                    '$description' => 'This event triggers when a document is upserted.',
-                ],
-                'delete' => [
-                    '$description' => 'This event triggers when a document is deleted.'
-                ],
+                'delete' => [
+                    '$description' => 'This event triggers when a document is deleted.'
+                ],
+                'upsert' => [
+                    '$description' => 'This event triggers when a document is upserted.',
+                ],

---

113-113: Nit: clarify wording for broader audiences

“Upserted” is correct, but some readers may not know the term. Small wording tweak improves clarity.

-                    '$description' => 'This event triggers when a document is upserted.',
+                    '$description' => 'This event triggers when a document is created or updated via an upsert operation.',

---

112-117: Verify 'upsert' event is actually emitted — route labels found, but no explicit emitter discovered

Quick summary: I searched the repo. The new config entry exists, and the databases controller declares event labels for upsert, and tests reference upsert flows — but I did not find explicit event-emission calls matching the "documents.*.upsert" pattern. Please confirm whether your framework emits events from the route/controller labels (->label('event', ...)) or whether an explicit emit needs to be added to the upsert code paths.

Files/locations to check:

• app/config/events.php — new 'upsert' entry (lines ~112–117)
• app/controllers/api/databases.php
  • ~4239: route for "Upsert document" with ->label('event', 'databases.[databaseId].collections.[collectionId].documents.[documentId].upsert') and ->label('audits.event', 'document.upsert')
  • ~4761: route for "Upsert documents" with ->label('audits.event', 'documents.upsert')
• tests/e2e/Services/Databases/DatabasesCustomServerTest.php — multiple upsert-related tests
• tests/e2e/Services/Databases/DatabasesBase.php — collection fixtures referencing upsert collections

Config snippet (unchanged):

                'upsert' => [
                    '$description' => 'This event triggers when a document is upserted.',
                ],
                'delete' => [
                    '$description' => 'This event triggers when a document is deleted.'
                ],

Requested action:

• Confirm where event emission occurs (framework-level label→emit mechanism or explicit emit).
• If no emitter exists for upsert, add emission(s) in the upsert code paths (single and bulk) and update/add tests.

I can help add the emit calls and tests once you confirm the desired emission mechanism.

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

Learnt from: ItzNotABug
PR: appwrite/appwrite#9693
File: src/Appwrite/Platform/Modules/Databases/Http/Databases/Tables/Indexes/Delete.php:40-40
Timestamp: 2025-06-25T06:25:45.054Z
Learning: In Appwrite's database module, the event label for deleting a table index intentionally uses 'update' (e.g., 'databases.[databaseId].tables.[tableId].indexes.[indexId].update') instead of 'delete', to match legacy behavior as seen in previous controller implementations.