Server Variables not working with Multiple Servers by Dart

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• What's the version of OpenAPI Generator used?
• Have you search for related issues/PRs?
• What's the actual output vs expected output?
• [Optional] Bounty to sponsor the fix (example)

Description

if you specify multiple servers with server variables in your yaml file, their URLs are not properly made available at template render time. Instead, it shows their URLs with the non-replaced variable names.

OpenAPI declaration file content or url

openapi: 3.0.0
info:
title: Account Kit Web API
description: HMS Account Kit Web API
version: 1.0.0
servers:

• url: https://oauth-login.cloud.huawei.com/oauth2/v3
  description: Host and Base Path of Account Kit(Obtain Access Token and Verifying ID Token)

paths:
/token:
post:
summary: obtain access token
operationId: obtainAccessToken
requestBody:
required: true
content:
application/x-www-form-urlencoded:
schema:
$ref: '#/components/schemas/obtainAccessToken_'
responses:
"200":
description: "OK!"
content:
application/json:
schema:
$ref: '#/components/schemas/obtainAccessToken_response'
"400":
description: "INVALID_REQUEST!"
content:
application/json:
schema:
$ref: '#/components/schemas/obtainAccessToken_response_failed'
/tokeninfo:
post:
summary: verifying ID token
operationId: verifyingIdToken
requestBody:
required: true
content:
application/x-www-form-urlencoded:
schema:
$ref: '#/components/schemas/verifyingIdToken_'
responses:
"200":
description: "OK!"
content:
application/json:
schema:
$ref: '#/components/schemas/verifyingIdToken_response'
"400":
description: "INVALID_REQUEST!"
/rest.php:
post:
summary: get token info
operationId: getTokenInfo
servers:
- url: https://oauth-api.cloud.huawei.com
description: Host and Base Path of Account Kit(Parsing Access Token)
parameters:
- in: query
name: nsp_fmt
required: true
schema:
type: string
default: JSON
- in: query
name: nsp_svc
required: true
schema:
type: string
default: huawei.oauth2.user.getTokenInfo
requestBody:
required: true
content:
application/x-www-form-urlencoded:
schema:
$ref: '#/components/schemas/getTokenInfo_'
responses:
"200":
description: "OK!"
content:
application/json:
schema:
$ref: '#/components/schemas/getTokenInfo_response'
"400":
description: "INVALID_REQUEST!"

components:
schemas:
obtainAccessToken_:
type: object
properties:
grant_type:
type: string
client_id:
type: string
client_secret:
type: string
code:
type: string
redirect_uri:
type: string
refresh_token:
type: string
verifyingIdToken_:
type: object
properties:
id_token:
type: string
getTokenInfo_:
type: object
properties:
access_token:
type: string
open_id:
type: string
obtainAccessToken_response:
type: object
properties:
token_type:
type: string
access_token:
type: string
scope:
type: string
expires_in:
type: integer
format: long
refresh_token:
type: string
id_token:
type: string
obtainAccessToken_response_failed:
type: object
properties:
error:
type: integer
sub_error:
type: integer
error_description:
type: string
verifyingIdToken_response:
type: object
properties:
typ:
type: string
alg:
type: string
kid:
type: string
iss:
type: string
sub:
type: string
aud:
type: string
exp:
type: integer
format: long
iat:
type: integer
format: long
nonce:
type: string
at_hash:
type: string
azp:
type: string
email_verified:
type: boolean
email:
type: string
picture:
type: string
name:
type: string
locale:
type: string
family_name:
type: string
given_name:
type: string
display_name:
type: string
getTokenInfo_response:
type: object
properties:
client_id:
type: integer
format: long
expire_in:
type: integer
union_id:
type: string
open_id:
type: string
scope:
type: string

Related issues/PRs

#6338

Suggest a fix

One potential fix is in the pull request noted above. PHP templates deal with this by rendering all of the server information into their configuration template/file, ignoring serverVariables specified on command line to openapi-generator (--serverVariables).

Best is probably to have all templates individually handle. Command line serverVariables should be added to the bundle that is supplied to templates, and individual language templates should fill in such variables at generator run-time.

For variables specified in the yaml/json file, they can remain un-substituted at generator run-time, and instead filled in with logic in the rendered templates.

Wdyt?

Start by reproducing the issue with the supplied OpenAPI declaration and the Dart generator, including multiple servers and --serverVariables. Read related issue #6338 and inspect how Dart templates receive server information; done means server URLs are correctly available at template render time with variables substituted or preserved as intended.