A suggestion regarding the compose method in RequestOptions.

[kajaha2k]

Request Statement

Hello,

I used to use your library without problems,
but I noticed something odd in RequestOptions.
The compose method is supposed to combine options with the base ones,
but I'm wondering why the connection timeout isn't merging properly with the base options."

Would it be possible for my suggestion to better align with the intended meaning of 'compose'?

connectTimeout: baseOpt.connectTimeout,
connectTimeout: connectionTimeout ?? baseOpt.connectTimeout,

 RequestOptions compose(
    BaseOptions baseOpt,
    String path, {
    Object? data,
    Map<String, dynamic>? queryParameters,
    CancelToken? cancelToken,
    ProgressCallback? onSendProgress,
    ProgressCallback? onReceiveProgress,
    StackTrace? sourceStackTrace,
  }) {
    final query = <String, dynamic>{};
    query.addAll(baseOpt.queryParameters);
    if (queryParameters != null) query.addAll(queryParameters);

    final headers = caseInsensitiveKeyMap(baseOpt.headers);
    if (this.headers != null) {
      headers.addAll(this.headers!);
    }
    if (this.contentType != null) {
      headers[Headers.contentTypeHeader] = this.contentType;
    }
    final String? contentType = headers[Headers.contentTypeHeader];
    final extra = Map<String, dynamic>.from(baseOpt.extra);
    if (this.extra != null) {
      extra.addAll(this.extra!);
    }
    final method = (this.method ?? baseOpt.method).toUpperCase();
    final requestOptions = RequestOptions(
      method: method,
      headers: headers,
      extra: extra,
      baseUrl: baseOpt.baseUrl,
      path: path,
      data: data,
      preserveHeaderCase: preserveHeaderCase ?? baseOpt.preserveHeaderCase,
      sourceStackTrace: sourceStackTrace ?? StackTrace.current,
      connectTimeout: baseOpt.connectTimeout,
      sendTimeout: sendTimeout ?? baseOpt.sendTimeout,
      receiveTimeout: receiveTimeout ?? baseOpt.receiveTimeout,
      responseType: responseType ?? baseOpt.responseType,
      validateStatus: validateStatus ?? baseOpt.validateStatus,
      receiveDataWhenStatusError:
          receiveDataWhenStatusError ?? baseOpt.receiveDataWhenStatusError,
      followRedirects: followRedirects ?? baseOpt.followRedirects,
      maxRedirects: maxRedirects ?? baseOpt.maxRedirects,
      persistentConnection:
          persistentConnection ?? baseOpt.persistentConnection,
      queryParameters: query,
      requestEncoder: requestEncoder ?? baseOpt.requestEncoder,
      responseDecoder: responseDecoder ?? baseOpt.responseDecoder,
      listFormat: listFormat ?? baseOpt.listFormat,
      onReceiveProgress: onReceiveProgress,
      onSendProgress: onSendProgress,
      cancelToken: cancelToken,
      contentType: contentType ?? this.contentType ?? baseOpt.contentType,
    );
    requestOptions.cancelToken?.requestOptions = requestOptions;
    return requestOptions;
  }

Solution Brainstorm

No response

[AlexV525]

No. The connect timeout is related to the adapter's implementation. Because the adapter holds inner clients to improve requests, the inner client will be used in requests of the same Dio instance, which shares the same connect timeout setting.

[kajaha2k]

Just as you mentioned, when utilizing an already established connection for improved performance, the connection timeout set during the request may not be crucial. However, in the scenario of a first-time request initiating a new Fetch, wouldn't it be meaningful to set a connectionTimeout during the request?

[AlexV525]

Changing the connect timeout in the base option will also update the setting in the client.

[kajaha2k]

Thank you for considering my suggestion.

If it's not problematic or too challenging, reflecting this would be appreciated.

[AlexV525]

I'm marking this as it won't be fixed based on the current design.