[fal.ai] flux-klein plugin: Conv2d padded input underflow — kernel (3×3) > input width (2px) causes chunk errors

[livepeer-tessa]

Summary

The flux-klein community plugin (installed from git+https://github.com/hthillman/scope-flux-klein) crashes with a Conv2d kernel size underflow error on every processed chunk when the input video is very narrow (2px wide after padding). This is the same class of error as #557 (VaceEncodingBlock) but occurring in the flux-klein plugin itself.

Error Frequency (2026-04-11 18:10–06:10 UTC, last 12h)

• 34 occurrences in session 90d3c3ae (20:11–~20:13 UTC)
• Error rate: ~2+ errors per second while active

Error Messages

2026-04-11 20:11:39,857 - scope.server.pipeline_processor - ERROR - Error processing chunk for flux-klein: Calculated padded input size per channel: (2 x 97). Kernel size: (3 x 3). Kernel size can't be greater than actual input size

2026-04-11 20:11:39,870 - scope.server.pipeline_processor - ERROR - Error processing chunk for flux-klein: Calculated padded input size per channel: (2 x 97). Kernel size: (3 x 3). Kernel size can't be greater than actual input size

Session Context

2026-04-11 20:08:32 - Installing plugin: git+https://github.com/hthillman/scope-flux-klein
2026-04-11 20:08:40 - Plugin installed: scope-flux-klein
2026-04-11 20:08:49 - Registered plugin pipeline: flux-klein
2026-04-11 20:09:33 - Loading pipeline: longlive (registry: flux-klein)
2026-04-11 20:10:46 - Parameter queue full for flux-klein, dropping parameter update (×4)
2026-04-11 20:11:39 - ERROR flood begins

Analysis

Input size (2 x 97) means the input width is only 2 pixels after whatever resizing/padding is applied — smaller than the 3×3 convolution kernel. The pipeline parameter queue was also full (dropping parameter update ×4), suggesting the pipeline was overwhelmed before the errors began.

The root cause is an input resolution too small for a convolution layer in the flux-klein plugin. The session used longlive as the pipeline type with flux-klein as the registry, suggesting this is a plugin that wraps longlive's architecture.

Related issues:

• VaceEncodingBlock fails on extremely narrow input images (kernel size > input size) #557 — VaceEncodingBlock: kernel size > input (extremely narrow images)
• VaceEncodingBlock temporal kernel underflow in streamdiffusionv2: (2 x 64 x 64) input < (3 x 1 x 1) kernel #673 — VaceEncodingBlock temporal kernel underflow
• krea-realtime-video / WAN2.1 VAE: Conv2d crashes with (2 × 513) input < (3 × 3) spatial kernel in VaceEncodingBlock #713 — WAN2.1 VAE: Conv2d with (2×513) input < (3×3) kernel

Fix approaches:

1. Add input size validation in the pipeline processor before running inference — reject/skip frames where min(height, width) < 3
2. Add a minimum resolution guard in the plugin or shared pipeline base class
3. Enforce minimum input dimensions in the graph executor before frames reach pipelines

Environment

• Service: fal.ai (plugin: scope-flux-klein v0.1.0 from github.com/hthillman/scope-flux-klein@776d67f)
• Session: 90d3c3ae
• Timestamp: 2026-04-11 20:11 UTC

[livepeer-tessa]

Opened PR #920 to fix this.

Root cause: pipeline_processor.py's exception handler has no rate-limiting for RuntimeError, so the Conv2d underflow fires as a full ERROR log on every single chunk (~2+ per second).

Fix (PR #920):

• Add a _is_conv2d_kernel_underflow() matcher for PyTorch's canonical message
• Add a new except RuntimeError handler in process_chunk() that rate-limits matching errors to one ERROR per 30 s (same pattern as the FileNotFoundError rate-limiter from VaceEncodingBlock fails when local Windows asset path is referenced on fal.ai backend #524)
• Non-matching RuntimeErrors fall through to the existing generic handler unchanged
• Pipeline stays alive and recovers if the user fixes the input resolution

This is a general fix covering any community plugin lacking minimum-resolution guards — not just flux-klein. The proper root-cause fix would be for flux-klein itself to validate min(H, W) >= kernel_size before running inference (as we did for the WAN VAE encoder in #713), but that's out of scope for this repo.