fix: validate string-list parameters across SDKs

[HarshMN2345]

Generated SDKs accepted any value for parameters the spec declares as an array of strings. Python crashed while serializing a non-string item (can only concatenate str (not "dict") to str), and Node, Web, Deno and React Native sent one as [object Object] without complaint. Services now validate these parameters from the schema, whatever the parameter is called, and every SDK's e2e prints the same responses for them.

Generated code

Each method calls the validator after its required-parameter checks, once per parameter whose schema is an array of strings (enum lists included), passing the nullable flag when the item schema is nullable. TablesDB.listRows from the Console spec, in Node:

Client.validateStringList('queries', queries);

Python, on Service:

def _validate_string_list(self, name: str, value: Any, nullable_items: bool = False) -> None:
    """Validate item types; generated required checks handle missing lists."""
    if value is None:
        return

    if not isinstance(value, list) or any(
        not isinstance(self._normalize_value(item), str) and not (nullable_items and item is None) for item in value
    ):
        expected = 'strings or None' if nullable_items else 'strings'
        raise AppwriteException(
            f'Invalid parameter: "{name}" must be a list of strings.',
            type='sdk_input_validation',
        )

Node, Web, React Native and Deno, on Client:

static validateStringList(
    name: string,
    value: unknown,
    nullableItems = false,
): void {
    // Missing values are left to the generated required-parameter checks.
    if (value === null || typeof value === 'undefined') {
        return;
    }

    if (
        !Array.isArray(value) ||
        value.some(
            (item) =>
                typeof item !== 'string' &&
                !(nullableItems && item === null),
        )
    ) {
        throw new AppwriteException(
            `Invalid parameter: "${name}" must be a list of strings.`,
            0,
            'sdk_input_validation',
        );
    }
}

PHP, on Service:

protected function validateStringList(string $name, ?array $value, bool $nullableItems = false): void
{
    if ($value === null) {
        return;
    }

    // Enum objects serialize to their string value.
    $valid = array_is_list($value) && array_all(
        $value,
        fn (mixed $item): bool => ($nullableItems && $item === null)
            || is_string($item instanceof \JsonSerializable ? $item->jsonSerialize() : $item)
    );

    if (!$valid) {
        throw new AppwriteException('Invalid parameter: "' . $name . '" must be a list of strings.', 0, 'sdk_input_validation');
    }
}

Ruby, on Service:

def validate_string_list(name, value, nullable_items: false)
    return if value.nil?
    return if value.is_a?(Array) && value.all? { |item| item.is_a?(String) || (nullable_items && item.nil?) }

    raise Appwrite::Exception.new("Invalid parameter: \"#{name}\" must be a list of strings.", 0, 'sdk_input_validation')
end

Callers get the SDK's exception with type sdk_input_validation, code 0 and no response, and no request is sent. String contents aren't inspected, so JSON query syntax is still validated by the API.

Swift/Apple, Kotlin/Android, Dart/Flutter, .NET/Unity, Go and Rust type these parameters as string lists, so a non-string item only gets in if the caller subverts the type system (an unchecked cast, or Dart's .cast<String>()). They get no validator.

Python's Client.flatten also picks the list index before building keys:

-            finalKey = prefix + '[' + key + ']' if prefix else key
-            finalKey = prefix + '[' + str(i) + ']' if isinstance(data, list) else finalKey
+            if isinstance(data, list):
+                finalKey = prefix + '[' + str(i) + ']'
+            else:
+                finalKey = prefix + '[' + key + ']' if prefix else key

PHP GET requests now prepare params the way JSON bodies are, so enum objects in query lists are sent as their values instead of being dropped by http_build_query.

E2E

Expected lines in tests/e2e/Base.php:

• ARRAY_PARAMETER_RESPONSES, every SDK: a string list with a non-JSON string and an enum value reaches the mock unchanged, in a query (listRows) and in a body (createDocuments labels). The mock's documents route now echoes documents and labels inside result, so typed models can print them; this replaces Swift and Apple's OBJECT_ARRAY_RESPONSES call.
• STRING_LIST_VALIDATION_RESPONSES, SDKs with the validator: the exception JSON for a query parameter (queries) and a body parameter (z), then nullable items passing.
• NESTED_LIST_RESPONSES, Python only: raw client.call with nested lists in a query string and in multipart fields.

Unity (licence disabled) and Deno are not in the CI matrix; their scripts follow the same contract.

Not in this PR

• Raw client.call with maps inside lists is mis-serialized outside Python (Kotlin/Android, Swift/Apple, .NET/Unity, Go, Rust, the JS family, Dart and Ruby). Generated methods don't send such values.
• The Swift client percent-encodes the joined query string with .urlHostAllowed, so & and = inside a value split it into extra parameters.

Addresses MCP-X; appwrite/mcp#117 consumes the new exception type.

[greptile-apps]

Confidence Score: 4/5

The PR is not safe to merge until Kotlin and Android again reject non-string list items supplied through JVM-erased Java or casted Kotlin calls.

Summary

• Adds string-list validators and generated calls for JavaScript-family, PHP, Python, and Ruby SDKs.
• Verifies query and body list values through observable mock-server responses.
• Fixes Python list-index selection during nested flattening.
• Converts PHP query enum objects to their serialized values.
• Removes Kotlin/Android validation despite Java generic erasure permitting invalid runtime values.

_{Reviews (8) · Last reviewed commit: "fix: leave Kotlin and Android string lis..."}

[HarshMN2345]

@greptile-apps Please refresh the review summary for current head 462184ab460e89d348ea78f98071f0715aad8592. The summary still lists the query-boundary finding, but your reassessment explicitly withdraws it under the updated, maintainer-requested spec-driven validation scope. The test-boundary finding is also addressed with real SDK calls and HTTP observation. No production changes were made after the reviewed head.

[ChiragAgg5k]

instead of this pattern of testing, we should follow existing pattern of logging the same response across all sdks. makes it concrete all sdks assert the same behaviour

[ChiragAgg5k]

try never print "passed". it should print a response specific to the test

[ChiragAgg5k]

lets update pr description to add code snippets of what new validation will be generated in the sdks as its hard to tell my twig templates