⚡ Bolt: [performance improvement] concurrent fileReader in useIconRegistry

[aafre]

💡 What: Refactored exportIconsForYAML inside useIconRegistry.ts to utilize Promise.all with a .map array instead of sequential for...of loops.

🎯 Why: The previous sequential looping structure meant that each icon's base64 extraction via FileReader had to complete before the next could begin. This caused an artificial I/O bottleneck when saving or exporting multiple images simultaneously.

📊 Impact: Reduces overall export times since extraction is parallelized across all uploaded icons.

🔬 Measurement: Verify changes in useIconRegistry.ts and ensure proper operation in local dev environments. All tests passed correctly.

---

PR created automatically by Jules for task 18328869234545640044 started by @aafre

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[gemini-code-assist]

Code Review

This pull request optimizes the icon export process in useIconRegistry.ts by replacing a sequential loop with concurrent processing via Promise.all. It also adds a learning entry to .Jules/bolt.md regarding this pattern. The review feedback suggests refining the documentation to warn about potential resource exhaustion when using Promise.all for external resources or large datasets without concurrency limits.

[gemini-code-assist]

The recommendation to "Always" use Promise.all for I/O-bound tasks is a bit too broad. While it is excellent for local operations like FileReader, using it for external API calls or extremely large datasets without concurrency control can lead to rate limiting, network congestion, or memory exhaustion. It would be better to qualify this advice by mentioning that concurrency should be managed (e.g., using a pool or a library like p-limit) when dealing with external resources or very large batches.

Suggested change

	**Action:** Always wrap independent I/O-bound mappings like `FileReader` parsing inside `Promise.all` mapping arrays to execute conversions concurrently, while retaining standard `try/catch` wrappers within the mapping function so single-file extraction failures do not abort the entire batch.
	Action: Wrap independent I/O-bound mappings like FileReader parsing inside Promise.all mapping arrays to execute conversions concurrently. For external resources or very large datasets, consider managing concurrency (e.g., with a pool) to avoid resource exhaustion. Retain try/catch wrappers within the mapping function so single-file failures do not abort the batch.

References

1. Ensure documentation is updated to reflect implementation details and best practices, such as managing concurrency for I/O-bound tasks.

[aafre]

Closing: superseded by #421 (cleanest version). Cherry-picked into #457.

[google-labs-jules]

Closing: superseded by #421 (cleanest version). Cherry-picked into #457.

Understood. Acknowledging that this PR has been superseded and the work is now obsolete. Stopping work on this task.