Offload local image byte reads off the event loop

[groupthinking]

Move Azure and Google vision local image file reads into worker threads via asyncio.to_thread without changing URL/error behavior.

[linear-code]

GRV-246

[github-actions]

👋 Thanks for opening this issue! It has been automatically labeled for triage.

[coderabbitai]

⚠️ Possible Duplicate Issue(s)

• GRV-244
• perf: Azure and Google vision providers read local image bytes on the event loop #1232

🔗 Related PRs

#1205 - perf(cloud-ai): run AWS Rekognition boto3 calls off the event loop [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[groupthinking]

Checked this against the shipped source on main. Already done — closing as resolved, not as stale.

Both reads this issue asks for are already offloaded:

File	Line on main
providers/azure_vision.py	return await asyncio.to_thread(_read_file_bytes, image_url) (L262)
providers/google_cloud.py	image.content = await asyncio.to_thread(_read_file_bytes, image_url) (L191)

Delivered by merged PR #1233, which closed its canonical issue #1232 as COMPLETED at 2026-08-02T15:15:54Z. This issue was created 14 seconds later, at 15:16:08Z — an automation race, not a genuine second report. (Same pattern as #1231 vs #1227/#1228, filed 16 seconds apart.)

I did not take the timestamps as sufficient proof. I also checked for a missed call site of the same defect class, since that's exactly what a duplicate-looking issue can hide — in #1231 that search found a real third call site the original PR overlooked. Here it didn't: aws_rekognition.py also offloads ({'Bytes': await asyncio.to_thread(_read_file_bytes, image_url)}, L487), so all three vision providers are covered and there is no residual gap.

One thing worth carrying forward: the deeper problem raised during review of #1233 is real and is not closed by this. All 66 asyncio.to_thread call sites share the bounded default executor, so one uninterruptible read (NFS/FUSE) permanently leaks a worker slot — cancelling the awaiting coroutine does not reclaim the thread. That's tracked separately in #1234, which I'm picking up next.