aglinxinyuan opened a new issue, #8400: URL: https://github.com/apache/texera/issues/8400
### Task Summary `FulltextSearchQueryUtils.usePgroonga` (`amber/src/main/scala/org/apache/texera/web/resource/dashboard/FulltextSearchQueryUtils.scala:32`) is a JVM-global `var`, production default `true`, read at exactly one site (`FulltextSearchQueryUtils.scala:52`) to select between the pgroonga arm and the `to_tsvector`/`to_tsquery` fallback. `WorkflowResourceSpec.beforeAll` forces it `false` and never restores it. amber declares no `Test / fork` (the two `Test / fork := true` settings in `build.sbt` belong to `ComputingUnitManagingService` and `FileService`) and serializes suites via `Tags.limit(Tags.Test, 1)` (`amber/build.sbt:48`), so a whole `WorkflowExecutionService/test` run — 193 completed suites — shares that one flag in one JVM. Once this suite has run, every suite scheduled after it sees the fallback arm instead of production's default. The suite does need the `false` arm and the write should not simply be deleted: its embedded Postgres has no pgroonga extension, and with the flag left `true` 11 of its 78 tests fail with `ERROR: function pgroonga_condition(unknown, fuzzy_max_distance_ratio => numeric) does not exist`. The fix is to capture the live value in `beforeAll` immediately before the write and put exactly that back as the first statement of `afterAll`, ahead of `closeConnectionPool()`. Capturing at construction time instead would restore whatever the flag held when sbt instantiated the class, which depends on sbt's scheduling rather than on what the suite clobbered. (Ordering the restore ahead of the teardown is hygiene rather than a live fix: `MockTexeraDB.closeConnectionPool` catches any `Exception` itself today.) This is latent leakage, not a currently-failing test: pinning the arm `false` for an entire module run leaves the failing-test identities byte-identical, so no suite in the module presently reads the flag in an arm-sensitive way. The restore is consequently unpinned — no existing test would go red if it were removed again — and it is not worth adding an ordering-dependent guard suite to manufacture a pin. One knock-on, tracked separately: `DatasetSearchQueryBuilderSpec`'s header comment states that both writers of this global set it and neither restores it. Fixing either writer makes that sentence false, so the paragraph is rewritten once — in the change that removes the other writer — into a form that names no suite and is therefore correct whichever fix lands first. `DatasetResourceSpec:99` performs the same unrestored write and is handled separately; that suite never reaches the flag read, so its write is deleted rather than restored. ### Task Type - [x] Refactor / Cleanup ### Was this issue authored using generative AI tooling? Generated-by: Claude Code (Opus 5) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
