## Summary `unique_id` keeps its counters in a process-global map, and `compile` clears that map on every call. Two `compile` calls running concurrently in one process therefore interfere: one call's reset lands between another call's `unique_id` calls, restarting its numbering mid-compile. The affected query ends up with several distinct sub-queries sharing one variable name. ## Impact For a multi-value `epic` / `parent` filter, each reference compiles to its own sub-query bound to its own variable. When the numbering restarts, those variables collide: ```graphql query GLQL($epicId4: WorkItemID!, $epicId1: WorkItemID!, $epicId1: WorkItemID!, $epicId1: WorkItemID!, ...) { project(fullPath: "gitlab-org/gitlab") { workItems(parentIds: [$epicId4, $epicId1, $epicId1, $epicId1], ...) { ``` Two consequences, the second worse than the first: 1. The document is invalid GraphQL — `UniqueVariableNames` rejects the duplicate definitions, so the query fails outright. 2. Four distinct epics collapse onto two variables, so even where such a document were accepted the filter would query the wrong set. This is silent. Exposure depends on the consumer. WASM in a browser is single-threaded and safe. The Ruby native extension is the realistic risk: any host calling `Glql.compile` from more than one thread in a process can hit this. ## Reproduction The test suite exposes it, because `cargo test` runs tests as threads in one process: ```shell rm -rf tmp/graphql DUMP_GRAPHQL=1 cargo test && npm run test:graphql # Detected 2 invalid documents: # - There can be only one variable named $epicId1. # - There can be only one variable named $parentId1. ``` Serialising the same suite removes the failures entirely, which isolates concurrency as the cause rather than any particular query: ```shell rm -rf tmp/graphql DUMP_GRAPHQL=1 cargo test -- --test-threads=1 && npm run test:graphql # 1442 documents, exit 0 ``` No individual test reproduces it — I ran all 192 tests in `work_items_tests.rs` one at a time against a cleaned dump directory and neither invalid document appeared. It needs two compiles racing. Compiling the same queries with a fresh `Context` yields correct, distinct keys (`epicId1` … `epicId4`). ## Root cause - `src/utils/common.rs:7-20` — `COUNTERS` is a `lazy_static! { Mutex<HashMap<String, usize>> }`, global to the process, and `unique_id` increments it. - `src/lib.rs:132` — `compile` calls `reset_unique_id_counters()`, clearing the global map at the start of every compile. The mutex makes each individual increment safe, but the counter's *lifetime* is wrong: it is shared across compiles that should be independent, and the reset is how one compile stomps another. ## Suggested direction Scope the counters to a single compile rather than the process — for example move the map onto `Context` (which is already threaded through `field_mapping.rs` and is where `variables` lives), so `unique_id` becomes a method on it and no reset is needed. That removes the global and the cross-compile interference together. ## Why this has stayed hidden - **The tests cannot catch it.** `tests/work_items_tests.rs` builds its expected query string out of `context.variables[i].key` — the actual keys — and only checks each one matches the pattern `epicId<digits>`. A collision satisfies both, so the assertion is self-fulfilling. - **CI cannot catch it.** The `test` job runs `cargo nextest run`, which executes each test in its own process. Without intra-process concurrency the race never fires, so `graphql-validate` is green even on commits where the local `cargo test` route produces the two invalid documents. ## Scope Pre-existing on `main`; reproduced at 457fe9e with no other changes applied. Found while adding `createdByDuo` / `acceptanceRate` for gitlab-org/glql#211; unrelated to that work, so reported rather than fixed there.