Closed
Description
Problem statement
Generated client breaks when downloading binary data
Caveats:
- I understand this concept isn't fully settled even in the Swagger/OpenAPI realm
- I am totally willing to hear that this is out-of-scope
- This may be limited to the endpoint sending a
Content-Typeofplain/text, but I haven't been able to test it
Swagger specification
---
swagger: "2.0"
info:
description: "Chunked Encoding Example"
version: "1.0.0"
title: "Jigsaw"
basePath: "/"
schemes:
- "https"
paths:
# https://jigsaw.w3.org/HTTP/ChunkedScript
/HTTP/ChunkedScript:
get:
summary: "chunked"
description: "delivers text/plain via Encoding: Chunked"
operationId: "chunked"
responses:
200:
description: "chunked data delivered"
schema:
type: string
format: binarySteps to reproduce
Generate the client
$ swagger generate client -f ./swagger.yml
Write a test to use the client, and download the data into a bytes.Buffer
func TestChunked(t *testing.T) {
transport := httptransport.New("jigsaw.w3.org", "/", []string{"https"})
c := client.New(transport, nil).Operations
buf := bytes.NewBufferString("")
ok, err := c.Chunked(operations.NewChunkedParams(), buf)
if err != nil {
t.Errorf("Unexpected error: %v\n", err)
}
t.Logf("Result: %v\n", ok)
}Run the test
$ go test ./...
--- FAIL: TestChunked (0.82s)
panic: interface conversion: interface {} is *bytes.Buffer, not *string [recovered]
panic: interface conversion: interface {} is *bytes.Buffer, not *string
goroutine 35 [running]:
panic(0x2a48a0, 0xc420434100)
/usr/local/Cellar/go/1.7.1/libexec/src/runtime/panic.go:500 +0x1a1
testing.tRunner.func1(0xc4200a4240)
/usr/local/Cellar/go/1.7.1/libexec/src/testing/testing.go:579 +0x25d
panic(0x2a48a0, 0xc420434100)
/usr/local/Cellar/go/1.7.1/libexec/src/runtime/panic.go:458 +0x243
github.com/go-openapi/runtime.TextConsumer.func1(0x43b300, 0xc420434080, 0x2e76e0, 0xc42027e770, 0xc42034e100, 0x43b300)
/Users/nelz/code/onbeep/go/src/github.com/go-openapi/runtime/text.go:34 +0x150
github.com/go-openapi/runtime.ConsumerFunc.Consume(0x31f6a0, 0x43b300, 0xc420434080, 0x2e76e0, 0xc42027e770, 0xcff0, 0xc42004dbd0)
/Users/nelz/code/onbeep/go/src/github.com/go-openapi/runtime/interfaces.go:48 +0x4e
github.com/nelz9999/scratchpad/jigsaw/client/operations.(*ChunkedOK).readResponse(0xc42034e1b0, 0x43fbc0, 0xc4202d8120, 0x43c180, 0x31f6a0, 0x0, 0x0, 0xc42034e120, 0xa)
/Users/nelz/code/onbeep/go/src/github.com/nelz9999/scratchpad/jigsaw/client/operations/chunked_responses.go:59 +0xd6
github.com/nelz9999/scratchpad/jigsaw/client/operations.(*ChunkedReader).ReadResponse(0xc420259fe0, 0x43fbc0, 0xc4202d8120, 0x43c180, 0x31f6a0, 0x1, 0x0, 0x0, 0x0)
/Users/nelz/code/onbeep/go/src/github.com/nelz9999/scratchpad/jigsaw/client/operations/chunked_responses.go:27 +0x103
github.com/go-openapi/runtime/client.(*Runtime).Submit(0xc42027c410, 0xc4200a4300, 0x0, 0x0, 0x0, 0x0)
/Users/nelz/code/onbeep/go/src/github.com/go-openapi/runtime/client/runtime.go:322 +0xa87
github.com/nelz9999/scratchpad/jigsaw/client/operations.(*Client).Chunked(0xc420259fa0, 0xc420259fc0, 0x43a880, 0xc42027e770, 0x0, 0x8, 0x1)
/Users/nelz/code/onbeep/go/src/github.com/nelz9999/scratchpad/jigsaw/client/operations/operations_client.go:49 +0x28c
github.com/nelz9999/scratchpad/jigsaw.TestChunked(0xc4200a4240)
/Users/nelz/code/onbeep/go/src/github.com/nelz9999/scratchpad/jigsaw/chunked_test.go:17 +0x268
testing.tRunner(0xc4200a4240, 0x31f740)
/usr/local/Cellar/go/1.7.1/libexec/src/testing/testing.go:610 +0x81
created by testing.(*T).Run
/usr/local/Cellar/go/1.7.1/libexec/src/testing/testing.go:646 +0x2ec
FAIL github.com/nelz9999/scratchpad/jigsaw 0.837s
? github.com/nelz9999/scratchpad/jigsaw/client [no test files]
? github.com/nelz9999/scratchpad/jigsaw/client/operations [no test files]
Investigations
- My not-so-secret end goal is to have streaming (aka Chunked) binary uploads and downloads via the generated clients. This is just the first easily describable bug I've been able to isolate.
- From my half-formed understanding of how the generated client works, I might suggest that any endpoint with a
type: string, format: binarysignature should have something like aBinaryConsumer/BinaryProducerthat supercedes anything relating to theContent-Type.