What causes "failed to write buffered data: %v" in wavetermdev/waveterm?

Treat client-disconnect errors as benign: check r.Context().Err() before propagating.

failed to write buffered data: %v

Error message

failed to write buffered data: %v

What it means

ServeFileOption chose the option.File branch and had buffered bytes to flush first; writing that buffered prefix to the http.ResponseWriter failed. As with the data branch, this usually means the client went away or the connection broke mid-response, so the buffered head of the file could not be delivered and the handler aborts.

Source

Thrown at pkg/waveapp/waveapp.go:427

	}

	// Handle the content based on the option type
	switch {
	case option.FilePath != "":
		filePath := wavebase.ExpandHomeDirSafe(option.FilePath)
		http.ServeFile(w, r, filePath)

	case option.Data != nil:
		w.Header().Set("Content-Length", fmt.Sprintf("%d", len(option.Data)))
		w.WriteHeader(http.StatusOK)
		if _, err := w.Write(option.Data); err != nil {
			return fmt.Errorf("failed to write data: %v", err)
		}

	case option.File != nil:
		if bufferedData != nil {
			if _, err := w.Write(bufferedData); err != nil {
				return fmt.Errorf("failed to write buffered data: %v", err)
			}
		}
		if _, err := io.Copy(w, option.File); err != nil {
			return fmt.Errorf("failed to copy from file: %v", err)
		}

	case option.Reader != nil:
		if bufferedData != nil {
			if _, err := w.Write(bufferedData); err != nil {
				return fmt.Errorf("failed to write buffered data: %v", err)
			}
		}
		if _, err := io.Copy(w, option.Reader); err != nil {
			return fmt.Errorf("failed to copy from reader: %v", err)
		}

	default:
		return fmt.Errorf("no content available")

View on GitHub (pinned to a4447c1563)

Solutions

Treat client-disconnect errors as benign: check r.Context().Err() before propagating.
Retry the load on the frontend side; the file itself is fine.
For large files, ensure buffering is bounded so the flush happens promptly before the client times out.
Verify the file handle is valid and readable before serving (a read error on bufferedData's source can surface here).
Check Wave logs to confirm whether the write error correlates with a canceled request.

Example fix

// before
if _, err := w.Write(bufferedData); err != nil {
    return fmt.Errorf("failed to write buffered data: %v", err)
}
// after
if _, err := w.Write(bufferedData); err != nil && r.Context().Err() == nil {
    return fmt.Errorf("failed to write buffered data: %v", err)
}

Defensive patterns

Strategy: try-catch

Validate before calling

if option.File == nil {
    return fmt.Errorf("no file to serve")
}
if r.Context().Err() != nil {
    return nil // request already canceled
}

Try / catch

if _, err := w.Write(bufferedData); err != nil {
    if r.Context().Err() != nil {
        return nil // client disconnected mid-stream; benign
    }
    return fmt.Errorf("failed to write buffered data: %v", err)
}
if _, err := io.Copy(w, option.File); err != nil {
    return fmt.Errorf("failed to copy from file: %v", err)
}

Prevention

Verify the file opens and reads correctly before serving.
Bound the buffered prefix so flushes happen promptly.
Check r.Context().Err() to filter client-disconnect noise.
Log write failures at debug level; they are usually cancellations, not data corruption.

When it happens

Trigger: Serving a file option where the first chunk was buffered (e.g. sniffing content type) and the client disconnects before the flush, the request is canceled, or the connection resets mid-stream.

Common situations: User closing the Wave block while a file preview/stream loads; frontend aborting a slow fetch; large files over an interrupted local connection.

Related errors

AI-assisted analysis of wavetermdev/waveterm@a4447c1563 (2026-09-01). Data as JSON: /api/errors/e169f81c5682f8c5. Report an issue: GitHub.