fix: normalize order case in MongoDB adapter

[premtsd-code]

Summary

• MongoDB adapter's getOrder() does a strict match against Database::ORDER_ASC ('ASC') and Database::ORDER_DESC ('DESC')
• When the SDK sends lowercase 'asc'/'desc', it falls through to the default case and throws "Unknown sort order:asc"
• Added strtoupper() to normalize the input before matching

Root cause

The Appwrite backend's index creation WhiteList validator accepts lowercase orders (non-strict mode lowercases for comparison), but stores the original lowercase value. When the database worker processes the index, it passes the stored lowercase value to getOrder() which rejects it.

Document sorting is unaffected because Query::groupByType() maps order queries to uppercase Database::ORDER_ASC/Database::ORDER_DESC constants — a completely separate code path that never touches the SDK's OrderBy enum values.

• WhiteList accepts lowercase: https://github.com/appwrite/appwrite/blob/1.9.x/src/Appwrite/Platform/Modules/Databases/Http/Databases/Collections/Indexes/Create.php#L76
• Orders stored as-is (lowercase from SDK): https://github.com/appwrite/appwrite/blob/1.9.x/src/Appwrite/Platform/Modules/Databases/Http/Databases/Collections/Indexes/Create.php#L194

Test plan

• Create an index on a DocumentsDB (MongoDB) collection with lowercase order values (asc/desc)
• Verify index creation succeeds without "Unknown sort order" error
• Verify existing uppercase order values still work
• Verify document sorting still works correctly

[coderabbitai]

📝 Walkthrough

Walkthrough

The Mongo::getOrder() method was updated to perform case-insensitive matching of sort order strings by applying strtoupper() inside the match expression, allowing callers to pass order constants in any case while still correctly mapping to the appropriate numeric sort direction.

Changes

Cohort / File(s)	Summary
Case-insensitive sort order normalization src/Database/Adapter/Mongo.php	Updated getOrder() method to apply strtoupper() inside the match expression for case-insensitive comparison of sort order strings.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Poem

🐰 A hop, a skip, through database lands,
Where ORDER_ASC in different hands,
Now matches true, both big and small,
strtoupper() answers the sort order call!

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title directly and clearly summarizes the main change: normalizing order case in the MongoDB adapter to handle case-insensitive sort order values.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/mongo-order-case

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[greptile-apps]

Greptile Summary

This PR adds \strtoupper() to the getOrder() helper in the MongoDB adapter so that lowercase 'asc'/'desc' values (e.g. from the DocumentsDB SDK) no longer throw "Unknown sort order". The fix is correct for the error it targets, but the normalization is incomplete: a case-sensitive comparison remains in the cursor-before direction-flip logic (line 2077), meaning that lowercase input will produce silently wrong sort direction for CURSOR_BEFORE paginated queries.

• getOrder() fix is correct and resolves the visible exception for index creation and simple queries.
• CURSOR_BEFORE pagination regression: if a lowercase order value reaches line 2077, the === Database::ORDER_ASC strict comparison fails, the direction is NOT flipped, and the query silently returns results in the wrong order.
• The recommended fix is to apply strtoupper() right after filter() on $orderType at line 2072 to make normalization consistent throughout the function.

Confidence Score: 3/5

The fix partially resolves the reported issue but introduces a silent correctness regression for CURSOR_BEFORE paginated queries with lowercase sort orders.

A P1 logic bug remains: after the fix, a CURSOR_BEFORE query with a lowercase order value will silently return results sorted in the wrong direction instead of throwing an exception. This is a present, reproducible defect on the changed code path and should be addressed before merging.

src/Database/Adapter/Mongo.php — specifically the cursor-direction reversal block around line 2077 and the $orderType assignment at line 2072.

Important Files Changed

Filename	Overview
src/Database/Adapter/Mongo.php	Adds strtoupper() in getOrder() to tolerate lowercase order values, but leaves case-sensitive comparisons in the CURSOR_BEFORE direction-flip logic, which can produce silently incorrect sort direction when lowercase input is used with cursor pagination.

Comments Outside Diff (1)

1. src/Database/Adapter/Mongo.php, line 2077-2079 (link)

   Incomplete case normalization breaks CURSOR_BEFORE sort direction

   The strtoupper() fix in getOrder() correctly allows lowercase input to resolve to a valid sort integer, but the cursor-direction reversal logic at line 2077 still uses a strict case-sensitive equality check against Database::ORDER_ASC ('ASC').

   If $orderType (and therefore $direction) arrives as lowercase 'asc':

   1. $direction === Database::ORDER_ASC → 'asc' === 'ASC' → false
   2. The ternary falls to the else-branch and sets $direction = Database::ORDER_ASC (ascending)
   3. $this->getOrder('ASC') returns 1 — but it should have been flipped to Database::ORDER_DESC → -1

   The result is a silently wrong sort direction for any CURSOR_BEFORE paginated query using lowercase order values. Before this PR such queries threw an exception; now they silently return results in the wrong order.

   The cleanest fix is to normalize $orderType immediately after filter():

   (The same strtoupper normalization should be applied at the equivalent sites on lines 505–529 and 976–986 where $orders[$j]/$orders[$i] feeds index creation.)

_{Reviews (1): Last reviewed commit: "fix: normalize order case in MongoDB ada..." | Re-trigger Greptile}