Autoparser: add optional argument reshuffle capability

[pwilkin]

Requires #18675

Some of the models that use tagged parsers (i.e. those that use quasi-XML tags for the arguments and their values) prefer a certain argument order with certain common tools. However, currently the grammar enforces the order in which the arguments are declared. If the tool tries to fill one optional argument first, it will be unable due to the grammar constraint to fill the other argument.

This manifests most often in failed calls to read_file tools which have an optional limit and offset parameter.

Fixes #20164

[aldehir]

I'd rather just do this for any number of optional arguments. Presumably a model should know not to generate a duplicate argument, but we will accept it since the JSON parser doesn't care.

[pwilkin]

You mean just ignore the shuffle and use the "else" branch as the universal solution?

I think the overhead for building the permutations for 4 options is really small (only 24 branches) and it does add a bit of reliability for what I feel is a large number of cases. Unless you think we should just keep it uniform with the JSON parser.

[aldehir]

Yes. I simply don't see the need for the added complexity of permutations. A repetition of choice is more than good enough, IMO.

[aldehir]

Maybe try it out and see if there are any problems?

This problem also exists for the JSON tool calling parsers that still enforce order because of json-schema-to-grammar. However, we can explode the arguments out like the XML parsers with a repetition that has a leading comma.

[CISC]

Agreed, the permutations are likely completely unnecessary.

[pwilkin]

Fine, no shuffle.

[aldehir]

Someone's gotta reel in your genius.

[pwilkin]

You meant "chaos", right? ;)

[MikeLP]

Idk is it right place to report issue (latest unsloth qwen3.5 35b)

{"error":{"code":400,"message":"Unable to generate parser for this template. Automatic parser generation failed: \n------------\nWhile executing CallExpression at line 145, column 28 in source:\n... {%- else %}↵        {{-
raise_exception('Unexpected message role.') }}↵    {%- ...\n                                           ^\nError: Jinja Exception: Unexpected message role.","type":"invalid_request_error"}}

Is it known issue?

[aldehir]

@MikeLP, seems like your client is using a developer role which is only supported by gpt-oss. I'd look into seeing if this can be turned off, i.e. use the system role instead. It's not really relevant to this PR.

[pwilkin]

@MikeLP You have to modify your template to treat developer role as system. It's a known problem with using OpenAI tools, sadly.

[MikeLP]

@MikeLP You have to modify your template to treat developer role as system. It's a known problem with using OpenAI tools, sadly.

Thanks for quick response.

[aldehir]

No need for this anymore.