OpenAPITools / OpenAPITools/openapi-generator
[BUG] [Dart] Response type of application/octet-stream with format: binary are unusable
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 26.8k
- Forks
- 7.7k
- PR merge metrics
- PR metrics pending
Description
Bug Report Checklist
- Have you provided a full/minimal spec to reproduce the issue?
- Have you validated the input using an OpenAPI validator (example)?
- Have you tested with the latest master to confirm the issue still exists?
- Have you searched for related issues/PRs?
- What's the actual output vs expected output?
- [Optional] Sponsorship to speed up the bug fix or feature request (example)
Description
An endpoint which returns binary data defined as
schema:
type: string
format: binary
Will fail in the following ways:
- Declare the function's return type to be
MultipartFile, which is only really valid for file upload, not for file download. - Attempt to read the response data via the
Response.Bodyfield, which defaults to attempting to deserialize as a string. For true binary data, this isn't valid. This will throw an exception at runtime.
As a result, true binary data response endpoints (as in, not b64 encoded responses), are unrepresentable in the current Dart generator.
see also: https://swagger.io/docs/specification/data-models/data-types/#file
openapi-generator version
6.0.0
OpenAPI declaration file content or url
openapi: 3.0.3
info:
version: "1.1"
title: Dart Uint8list Demo
servers:
- url: 'localhost'
variables:
host:
default: localhost
paths:
/item:
get:
operationId: GetItem
responses:
"200":
description: Binary data
content:
application/octet-stream:
schema:
type: string
format: binary
The generated method looks like this:
Future<MultipartFile?> getItem() async {
final response = await getItemWithHttpInfo();
if (response.statusCode >= HttpStatus.badRequest) {
throw ApiException(response.statusCode, await _decodeBodyBytes(response));
}
// When a remote server returns no body with a status of 204, we shall not decode it.
// At the time of writing this, `dart:convert` will throw an "Unexpected end of input"
// FormatException when trying to decode an empty string.
if (response.body.isNotEmpty && response.statusCode != HttpStatus.noContent) {
return await apiClient.deserializeAsync(await _decodeBodyBytes(response), 'MultipartFile',) as MultipartFile;
}
return null;
}
Steps to reproduce
java -jar openapi-generator-cli.jar generate -i ./spec.yaml -g dart -o uint- use the getItem() method
Related issues/PRs
https://github.com/OpenAPITools/openapi-generator/issues/8878
Suggest a fix
- Response types of
application/octet-streamand schema declarations oftype: string, format: binaryshould use theUInt8Listdatatype, not the MultipartFile. Request types should remain unchanged. - Responses should be deserialized with
request.bodyBytes, notrequest.Body, to avoid decoding exceptions
It also looks like the dart-dio-next generator handles this fine -- using -g dart-dio-next I get Response<Uint8List> instead of Response<MultipartFile>
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the Dart generator's response handling for the provided OpenAPI spec and compare it with the dart-dio-next output. Trace the generated getItem method, apiClient.deserializeAsync, and response body handling. Done means binary responses use Uint8List and body bytes without breaking request MultipartFile handling; regenerate the sample to verify the result.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- dart
- Domain
- api, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100