ImageGenerationServiceImpl.generateImage crashes with EXC_BREAKPOINT on Qwen Image Edit 2511 over gRPC

ImageGenerationServiceImpl.generateImage crashes the gRPC server with EXC_BREAKPOINT (SIGTRAP) when calling GenerateImage on Qwen Image Edit 2511 (6-bit) (qwen_image_edit_2511_q6p.ckpt) with a minimal request (no input image, plain text-to-image). This looks like the same class of bug as #76 (closed, FLUX.2 [dev] kontext modifier) — possibly a regression, or the fix didn't cover this model's modifier path. Crash is reproducible: happened 3 times in a row with slightly different request field sets (with/without scaleFactor set). **Environment** - macOS 26.6 (25G72) - Draw Things app: 1.20260716.0 - Chip: Apple M4 Pro, 24 GB unified memory - Model: qwen_image_edit_2511_q6p.ckpt (Qwen Image Edit 2511, 6-bit), loaded via external model folder - API Server: gRPC, TLS enabled, port 7859, IP 0.0.0.0, no shared secret - Client: hand-written Python client using grpcio + generated bindings from imageService.proto / config.fbs (this repo, same commit as the shipped app version) **Steps to reproduce** - Enable gRPC API Server in Draw Things Settings (Advanced → API Server → Enable, Protocol: gRPC, TLS: Enable) - Load qwen_image_edit_2511_q6p.ckpt as the active model in a project - Send a GenerateImage request over gRPC with: - prompt: any short text prompt - configuration: FlatBuffer-encoded GenerationConfiguration with model = "qwen_image_edit_2511_q6p.ckpt", start_width = 1024, start_height = 1024, seed = 42, steps = 30, guidance_scale = 4.5, strength = 1.0, sampler = UniPC, batch_count = 1, batch_size = 1 — all other fields left at schema defaults - no image, mask, hints, or contents set - scaleFactor tested both unset (0) and explicitly 1 — crashes either way **Expected behaviour** Same output as draw-things-cli generate --model qwen_image_edit_2511_q6p.ckpt --prompt "..." on the same machine, same model — which succeeds and returns a valid PNG (confirmed working, ~13 min for a 30-step 1024x1024 generation on this hardware). **Actual behaviour** The app crashes outright (not just the gRPC connection dropping — the whole DrawThings process terminates with SIGTRAP, requiring a full relaunch). Confirmed via macOS crash report, not just a client-side timeout. **Crash report (relevant thread only)** ``` Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000001, 0x0000000100ed8b4c Termination Reason: Namespace SIGNAL, Code 5, Trace/BPT trap: 5 Triggered by Thread: 4, Dispatch Queue: com.draw-things.edit Thread 4 Crashed:: Dispatch queue: com.draw-things.edit 0 DrawThings 0x100ed8b4c ImageGenerationServiceImpl.generateImage(configuration:request:fileMapping:promise:context:responseCompression:cancelFlag:successFlag:cancellation:cancel:) + 19228 1 DrawThings 0x100ed3ff8 closure #2 in closure #4 in ImageGenerationServiceImpl.generateImage(request:context:) + 344 2 DrawThings 0x100ee5094 partial apply for closure #2 in closure #4 in ImageGenerationServiceImpl.generateImage(request:context:) + 84 3 DrawThings 0x100787f14 thunk for @escaping @callee_guaranteed @Sendable () -> () + 28 4 libdispatch.dylib 0x18a46fa28 _dispatch_call_block_and_release + 32 5 libdispatch.dylib 0x18a4894b0 _dispatch_client_callout + 16 6 libdispatch.dylib 0x18a478030 _dispatch_lane_serial_drain + 740 7 libdispatch.dylib 0x18a478b2c _dispatch_lane_invoke + 392 8 libdispatch.dylib 0x18a482e34 _dispatch_root_queue_drain_deferred_wlh + 284 9 libdispatch.dylib 0x18a482734 _dispatch_workloop_worker_thread + 720 10 libsystem_pthread.dylib 0x18a627ec0 _pthread_wqthread + 292 11 libsystem_pthread.dylib 0x18a626c10 start_wqthread + 8 ``` **Possible relation to #76** #76 diagnosed a nearly identical crash (same top frame, EXC_BREAKPOINT, same com.draw-things.edit queue) for FLUX.2 [dev] with the kontext modifier, root-caused to randomLatentNoise computing the wrong latent shape (dims multiplied by 8 instead of divided, double channel count) because the modifier was applied unconditionally even without a reference image. Qwen Image Edit is also a modifier/edit-type model that expects extra input channels — this may be the same underlying issue in a different model family, either not fully fixed or reintroduced since #76 was closed in May.