fix: disable libvips operation cache to stop image-conversion memory leak

[lesnik512]

Problem

Long-running services that convert many uploads (e.g. an upload/S3 gateway) show steady process memory growth correlated with traffic that looks like a leak.

Root cause

FileValidator._convert_image converts every image with libvips via pyvips.Image.new_from_buffer(...).write_to_buffer(...). libvips keeps a process-global operation cache enabled by default (up to ~1000 operations, plus memory/file caps). Each cached operation pins references to its image buffers, so across conversions memory climbs until the caps are hit. Every upload is a unique buffer, so the cache never produces a hit: it is pure retained memory with no benefit for this workload.

This is the standard libvips-in-a-server behavior; pyvips' own examples/soak-test.py prevents it with pyvips.cache_set_max(0).

Measured (pyvips 3.1.1 / libvips 8.17.3)

Running the exact conversion in a loop and reading pyvips.cache_get_size():

• start: 0
• after 5 default conversions: 35 (one new_from_buffer decomposes into several cached ops, each pinning buffers)
• after cache_set_max(0): stays 0

Fix

Disable the libvips operation cache on the conversion path with pyvips.cache_set_max(0), guarded by a pyvips.cache_get_max() check so the setter effectively runs once. The import pyvips stays local to _convert_image. No public API change; conversion output, formats, quality, and error handling are unchanged.

Test

Added a TDD regression test asserting pyvips.cache_get_size() == 0 after a conversion. It only observes cache size (never mutates it), so it is order-independent: red on main (nonzero), green with the fix. Full suite: 36 passing, 100% coverage.

🤖 Generated with Claude Code