app/config/collections/platform.php (1)

334-344: Consider default value and index for the labels field.

Two observations:

1. Default value inconsistency: The default is set to null, but the controller initializes it as [] (line 207 in app/controllers/api/projects.php). Consider changing the default to [] for consistency.

2. Missing index: The labels field is included in ALLOWED_ATTRIBUTES for queries (see src/Appwrite/Utopia/Database/Validator/Queries/Projects.php), but there's no index defined. If filtering/querying by labels is expected to be common, consider adding an index to improve performance.

🔎 Proposed fix for default value

             [
                 '$id' => ID::custom('labels'),
                 'type' => Database::VAR_STRING,
                 'format' => '',
                 'size' => 128,
                 'signed' => true,
                 'required' => false,
-                'default' => null,
+                'default' => [],
                 'array' => true,
                 'filters' => [],
             ],

Note: For the index consideration, verify whether array field indexes are supported and beneficial in your database configuration before adding one.

tests/e2e/Services/Projects/ProjectsConsoleClientTest.php (1)

5492-5589: Minor test hygiene: second project cleanup and misleading comment

• The comment // Setup: Second project with only imagine label doesn’t match the data; project 2 gets ['vip', 'imagine'].
• The test deletes only $projectId and the team, but leaves $projectId2 around. In this suite, extra projects may affect tests that rely on global counts / ordering.

Consider:

• Updating the comment to reflect actual labels, and
• Deleting $projectId2 as part of the cleanup to keep the test self-contained.

src/Appwrite/Platform/Modules/Projects/Http/Projects/Labels/Update.php (2)

24-32: Add return type to getName() for consistency with other actions

getName() currently has no return type hint. To keep this aligned with typical Action implementations and avoid potential signature mismatches with the base class/interface, it’s safer to declare : string.

Also, since getQueriesValidator() returns a Projects validator but the action doesn’t accept queries, this override is effectively unused today. That’s fine, but if the base Action doesn’t expect queries here, you could drop it to reduce noise.

If the base Action (or an interface it implements) already defines public static function getName(): string, please update this method signature accordingly:

public static function getName(): string
{
    return 'updateProjectLabels';
}

Please verify against the current Action definition in your codebase.

---

59-82: Label validation and normalization considerations

The labels param is well-constrained (max count via APP_LIMIT_ARRAY_LABELS_SIZE, per-label length 36, alphanumeric only). The action also de-duplicates labels via array_unique.

If you want stricter consistency over time, you might also consider:

• Trimming whitespace from each label before validation.
• Normalizing case (e.g., lowercasing) so VIP and vip aren’t treated as distinct.

Not strictly required for correctness, but improves long-term data hygiene and query predictability.

If you decide to normalize, confirm with product/API docs that label matching is intended to be case-insensitive before changing behavior.

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

tests/e2e/Services/Projects/ProjectsConsoleClientTest.php (1)

5416-5442: Good coverage of label operations.

The test validates both applying initial labels and updating them. The assertions properly check array structure, count, and individual values. Note that the test assumes label order is preserved (lines 5427-5429, 5440-5441), which is appropriate if order preservation is part of the API contract.

Consider adding test cases for edge cases and failure scenarios, such as:

• Empty labels array (might already be covered by default state)
• Invalid label values (if any constraints exist)
• Duplicate labels in input
• Maximum label array size (if any limit exists)

These could help ensure robustness, though they may be covered in other test files.

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro