src/Appwrite/Platform/Modules/Schedules/Http/Schedules/Create.php (1)

106-108: DuplicateException catch swallows the root cause with a generic message.

Since schedules use auto-generated IDs, a DuplicateException here would indicate an unexpected collision. Logging the underlying exception or including a more specific error code would aid debugging.

tests/e2e/Services/Schedules/SchedulesCustomServerTest.php (3)

89-98: Test relies on validation ordering — consider using a valid resource ID.

This test sends an invalid cron with a non-existent resourceId. If the API validates the cron expression first, the 400 assertion holds. But if resource lookup is evaluated before cron validation in a future refactor, this test would break with a 404. Consider either:

• Using the functionId from a @depends on testCreateSchedule, or
• Adding resourceType => 'invalid' so that input validation is unambiguously triggered first.

This is minor since it works today, but it makes the test less resilient to implementation changes.

---

153-179: $data parameter is unused — consider using it to strengthen the test.

Static analysis flags $data as unused. Since @depends testCreateSchedule provides the scheduleId, you could use it to assert the created schedule actually appears in the listing, making this test more meaningful than just checking structure.

♻️ Suggested improvement

     public function testListSchedules(array $data): void
     {
+        $scheduleId = $data['scheduleId'];
+
         /**
          * Test for SUCCESS
          */
         $response = $this->listSchedules();
 
         $this->assertEquals(200, $response['headers']['status-code']);
         $this->assertIsArray($response['body']['schedules']);
         $this->assertGreaterThanOrEqual(1, $response['body']['total']);
         $this->assertGreaterThanOrEqual(1, \count($response['body']['schedules']));
 
+        // Verify the created schedule appears in the listing
+        $scheduleIds = array_column($response['body']['schedules'], '$id');
+        $this->assertContains($scheduleId, $scheduleIds);
+
         // Verify schedule structure
         $schedule = $response['body']['schedules'][0];

---

181-208: $data parameter is unused — same issue as testListSchedules.

Same recommendation as above: either use $data to verify the specific schedule appears in filtered results (strengthening the test), or document that @depends is purely for ordering.

src/Appwrite/Platform/Modules/Schedules/Http/Schedules/XList.php (1)

87-103: Cursor document is not validated for project ownership.

The cursor schedule is fetched without checking if it belongs to the requested project (line 94-96). While the projectId filter in the query set means results won't leak data from other projects, a cursor pointing to a schedule in a different project could cause unexpected empty results or confusing pagination behavior. Consider validating $cursorDocument->getAttribute('projectId') === $project->getId().

Proposed fix

         if ($cursorDocument->isEmpty()) {
             throw new Exception(Exception::GENERAL_CURSOR_NOT_FOUND, "Schedule '{$scheduleId}' for the 'cursor' value not found.");
         }
+
+        if ($cursorDocument->getAttribute('projectId') !== $project->getId()) {
+            throw new Exception(Exception::GENERAL_CURSOR_NOT_FOUND, "Schedule '{$scheduleId}' for the 'cursor' value not found.");
+        }

         $cursor->setValue($cursorDocument);

tests/e2e/Services/Schedules/SchedulesConsoleClientTest.php (2)

22-146: Consider adding test coverage for execution and message resource types.

The PR objective mentions resource validation for functions, executions, and messages, but only the function resource type is exercised here. Adding at least one success-path test for execution and message would improve confidence in the validation logic for all three types.

---

13-17: Missing test coverage for authentication/authorization enforcement.

The PR states that schedules endpoints use AuthType::ADMIN (console session). There are no tests verifying that unauthenticated requests or non-admin API key requests are rejected. Consider adding a test that omits the console session headers and asserts a 401 response to confirm admin-scope enforcement is working correctly.

tests/e2e/Services/Schedules/SchedulesConsoleClientTest.php (1)

151-182: Consider asserting resourceId matches the expected functionId.

The get-schedule success path validates most fields but doesn't verify that resourceId matches $data['functionId']. This would strengthen the assertion that the correct schedule was returned.

Suggested addition

 $this->assertEquals('function', $response['body']['resourceType']);
+$this->assertEquals($data['functionId'], $response['body']['resourceId']);
 $this->assertEquals('0 0 * * *', $response['body']['schedule']);

tests/e2e/Services/Schedules/SchedulesBase.php (1)

11-12: Consider renaming helper to avoid PHPUnit auto-discovery.

A test* method in a trait will be picked up as a test in every class using it. If this is intended as a helper, renaming prevents accidental execution.

♻️ Suggested rename

-    public function testCreateProject(): array
+    public function createProject(): array

🤖 Fix all nitpicks with AI agents

Before applying any fix, first verify the finding against the current code and
decide whether a code change is actually needed. If the finding is not valid or
no change is required, do not modify code for that item and briefly explain why
it was skipped.

In `@src/Appwrite/Platform/Modules/Schedules/Http/Schedules/Create.php`:
- Around line 131-144: The code in Create.php currently sets $attributes['data']
= \json_decode($data, true) without checking for decode errors; update the
Create handler to validate the result of \json_decode($data, true) (e.g., check
json_last_error() !== JSON_ERROR_NONE and use json_last_error_msg()) and if
decoding failed return/throw a proper validation/error response (or refuse to
persist) instead of silently assigning null to $attributes['data']; ensure you
reference the $data variable and $attributes array in this fix so any invalid
JSON from users causes a clear error rather than a null schedule data value.

src/Appwrite/Platform/Modules/Schedules/Http/Schedules/Create.php (1)

131-144: Missing error handling for json_decode on user-supplied data.

On line 143, \json_decode($data, true) is called without checking the result. While the JSON validator on line 91 should catch syntactically invalid JSON, if for any reason decoding fails, json_decode returns null and the schedule's data attribute would silently be set to null instead of the intended value.

Consider adding a guard:

Proposed fix

         if ($data !== null) {
-            $attributes['data'] = \json_decode($data, true);
+            $decoded = \json_decode($data, true);
+            if ($decoded === null && $data !== 'null') {
+                throw new Exception(Exception::GENERAL_ARGUMENT_INVALID, 'Invalid JSON data');
+            }
+            $attributes['data'] = $decoded;
         }

🤖 Prompt for AI Agents

Before applying any fix, first verify the finding against the current code and
decide whether a code change is actually needed. If the finding is not valid or
no change is required, do not modify code for that item and briefly explain why
it was skipped.
In `@src/Appwrite/Platform/Modules/Schedules/Http/Schedules/Create.php` around
lines 131 - 144, The code in Create.php currently sets $attributes['data'] =
\json_decode($data, true) without checking for decode errors; update the Create
handler to validate the result of \json_decode($data, true) (e.g., check
json_last_error() !== JSON_ERROR_NONE and use json_last_error_msg()) and if
decoding failed return/throw a proper validation/error response (or refuse to
persist) instead of silently assigning null to $attributes['data']; ensure you
reference the $data variable and $attributes array in this fix so any invalid
JSON from users causes a clear error rather than a null schedule data value.

src/Appwrite/Platform/Modules/Schedules/Http/Projects/Schedules/Create.php (1)

138-140: json_decode failure not handled.

If json_decode($data, true) fails (e.g., deeply nested JSON exceeding PHP's default depth), it returns null and json_last_error() would indicate an error. The JSON validator on the param likely catches most cases, but a malformed decode would silently set data to null.

This is unlikely to be an issue in practice given the upstream validator, but worth noting.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/Appwrite/Platform/Modules/Schedules/Http/Projects/Schedules/Create.php`
around lines 138 - 140, In Create.php the result of json_decode($data, true) is
not checked so a decode error silently sets $attributes['data'] to null; after
calling json_decode in the Create class/method check json_last_error() (or
json_last_error_msg()) and handle failures by returning or throwing a
validation/400-style error (or keeping the raw string) instead of assigning null
to $attributes['data']; update the logic around the $data handling and
$attributes['data'] assignment so only a successful decode (JSON_ERROR_NONE)
populates the attribute and any decode error produces an explicit error
response.