Autocomplete sends any string values for focused integer and number options

[Quahu]

Description

The autocomplete docs mention the following:

Your application will receive partial data for any existing user input, as long as that input passes client-side validation. For example, you may receive partial strings, but not invalid numbers.

Despite this, I'm observing an empty string being sent for an integer/number option.

I apologize if I used the wrong issue template, wasn't sure whether to pick the docs one or this one.

Steps to Reproduce

1. Use a slash command with the following options: (String, required), (Integer, required), (Integer/Number, optional). The second option has autocomplete disabled, not sure if it's relevant.
2. Specify the first two options and switch to the third.
3. Observe the invalid value being sent.

Expected Behavior

The API not sending invalid integers/numbers as this behavior is not documented.

Current Behavior

The API does send invalid integers/numbers.

Screenshots/Videos

Example JSON payload of the invalid data with irrelevant fields removed. You can see the third option's value being an empty string despite the type being 4, which is integer.

{
    "t": "INTERACTION_CREATE",
    "op": 0,
    "d": {
        "version": 1,
        "type": 4,
        "data": {
            "type": 1,
            "options": [
                {
                    "value": "a",
                    "type": 3,
                    "name": "first"
                },
                {
                    "value": 6,
                    "type": 4,
                    "name": "second"
                },
                {
                    "value": "",
                    "type": 4,
                    "name": "third",
                    "focused": true
                }
            ],
            "name": "test"
        }
    }
}

Client and System Information

Happens on both clients: Desktop: Stable 128650 (1339f8b) Host 1.0.9004 Windows 10 64-Bit (10.0.19043) Android: App: 129.1 - Alpha - 129201 - rn (null) canaryRelease; Manifest: N/A; Build Override: N/A; Device: GM1901, OnePlus7 OS 30;

[typpo]

Trying to understand the problem and it seems that sentence in the docs is misleading. Autocomplete interactions for typing-in-progress will send string values, including empty string. A numeric autocomplete shouldn't allow data to be submitted as an application command if it doesn't pass client validation though.

[Quahu]

~~I'd imagine the best solution would be to validate that the value's type matches the slash command option's type API-side. This way even if there's a bug in client code this won't leak through, but instead display an error in the client (or just get ignored silently)?~~

Misunderstood the above comment.

[night]

We could improve documentation for this, but receiving strings is working as intended for autocomplete. We do not process user input and pass that direct to bots for autocomplete suggestions. This includes empty string, which is the initial payload we send when a user starts autocomplete.

[Quahu]

Oh, so any string is valid if the user is focused on the option.

{
    "data": {
        "type": 1,
        "options": [
            {
                "value": 42,
                "type": 4,
                "name": "second"
            },
            {
                "value": "asdasd",
                "type": 4,
                "name": "third",
                "focused": true
            }
        ]
    },
}

(irrelevant fields omitted)

To me this seems pretty counter-intuitive, so I think it should be stated in the documentation that the client-side validation only applies to unfocused options.