Parallelize environment skill loading#29990
Conversation
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ee1a3e594a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3db9e2841d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| .await | ||
| { | ||
| }) | ||
| .buffered(MAX_CONCURRENT_SKILL_LOADS) |
There was a problem hiding this comment.
In term of defensive, this will be interesting because it means the executor can make the memory usage of the orchestrator explode through this. To me this is a potential attack surface
Why
Avoid a request waterfall for loading lots of skills at once by hiding latency in concurrent tasks.
What changed
Poll the per-skill parse futures concurrently with an order-preserving stream capped at 64 in-flight loads. Results retain discovery order, and the existing filtering, warnings, and final catalog sorting are unchanged.