Has anyone noticed composer 2 fast model, either severely hallucinating, or possibly bringing in knowledge/data from other clients?
It started trying to fix an issue as follows. The problem is that this is nothing that I have ever used in any project. There is no instance of “governor”, “GLOBAL_MAX_BROWSER_CONTEXTS”, “_scrape_targets”, or any other concepts below in my entire source tree over all projects, and there never has been.
This is not to do with any of my projects. It’s either hallucinated, or it has brought in data from another person’s project.
Has anyone else experienced this?
Adding a brief "Governor vs parallelism" note — GLOBAL_MAX_BROWSER_CONTEXTS=2 can cap concurrent work if we switch to per-task governor acquires (possible cause of "only 2 tabs").
### Governor (`global_max_browser_contexts`) vs parallel HTTP
Today, `_scrape_targets`-style functions **`await governor.acquire()` once per batch** then run several concurrent `scrape_target_via_node_*` calls **without** each acquiring the governor — so **`GLOBAL_MAX_BROWSER_CONTEXTS=2` does not cap in-flight Node POSTs within one job** (only one permit is held for the whole batch).
If implementation is refactored to **acquire the governor inside each concurrent leg** (one permit per in-flight Node scrape), then **`global_max_browser_contexts` must be ≥ the max concurrent telemetry writes you want** (e.g. raise it or set it ≥ `default_job_max_concurrency` for that scope). Otherwise you will see **at most `GLOBAL_MAX` concurrent “tabs”** regardless of `job_max_concurrency`. Call this out when wiring so “only 2” is not mistaken for a DDB key bug.