This is an automated email from the ASF dual-hosted git repository.
github-merge-queue[bot] pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/texera.git
The following commit(s) were added to refs/heads/main by this push:
new 71da882192 test(amber): drop the unused pgroonga override from
DatasetResourceSpec (#8403)
71da882192 is described below
commit 71da8821926a1e506c3fc5ba18760c792da7d223
Author: Xinyuan Lin <[email protected]>
AuthorDate: Sat Sep 5 06:04:18 2026 +0000
test(amber): drop the unused pgroonga override from DatasetResourceSpec
(#8403)
### What changes were proposed in this PR?
`DatasetResourceSpec.beforeAll` set the JVM-global
`FulltextSearchQueryUtils.usePgroonga` to `false`
and never put it back. The write did nothing for this suite and
everything to the suites after it.
**Why it does nothing here.** `usePgroonga` is read at exactly one place
in `src/main`:
`FulltextSearchQueryUtils.scala:52`. That read is inside
`getFullTextSearchFilter`, which is called
from exactly two places in `src/main` —
`VersionedResourceSearchQueryBuilder.scala:128` and
`WorkflowSearchQueryBuilder.scala:120`. `DatasetResourceSpec` reaches
neither with a keyword:
| step | what it does |
| --- | --- |
| the four tests | two use only `UserDao`; two call
`DatasetSearchQueryBuilder.constructQuery(uid,
SearchQueryParams(resourceType = DATASET_RESOURCE_TYPE), includePublic =
true)` |
| `SearchQueryBuilder.constructQuery` (`final`) | `constructFromClause`
+ `constructWhereClause` + `mappedResourceSchema.allFields` +
`getGroupByFields`; none of the first, third or fourth touches full-text
(`constructFromClause` only builds jOOQ joins, `getGroupByFields` is
`Seq.empty`) |
| `constructWhereClause` | reaches
`getFullTextSearchFilter(splitKeywords, List(DATASET.NAME,
DATASET.DESCRIPTION))` |
| `splitKeywords` | derived from `params.keywords`, which the tests
leave at its `new util.ArrayList[String]()` default
(`DashboardResource.scala:72`), so it is empty |
| `getFullTextSearchFilter` | `fields` is non-empty so the `:39` guard
does not fire, but `trimmedKeywords.isEmpty` returns `noCondition()` at
`:46` — **before** the `:52` read |
**Why it does something to everyone else.** amber has no `Test / fork`
and serialises its suites in
one JVM, so `false` stayed set for every suite scheduled after this one,
moving their full-text
rendering onto the `to_tsvector`/`to_tsquery` arm.
```
before: beforeAll: usePgroonga = false -> suite's own 4 tests: never
read it
-> every later suite in the JVM:
reads false
after: flag untouched at its production default true
```
So the write is deleted rather than captured and restored. A
capture-and-restore would still leave
the value wrong *during* this suite and would depend on when the suite
object is constructed and on
where sbt happens to schedule it; deleting the write removes the leak
unconditionally.
Also removed, from the same copy-paste block:
- `private def getKeywordsArray`, which has no caller. After the
deletion the only `getKeywordsArray`
in the repository is `WorkflowResourceSpec`'s own `private` copy
(definition at `:201`, 16 call
sites, all in that file). Being `private`, this file's copy could only
ever have been called from
this file, and was not.
- `import
org.apache.texera.web.resource.dashboard.{FulltextSearchQueryUtils}` and
`import java.util`,
which were the only imports those two members needed.
A short comment replaces the write, recording that the flag is left at
its production default because
no test here reaches the read, and what a keyword test added here would
have to do instead
(`MockTexeraDB` strips the full-text index block out of the DDL, so the
embedded Postgres has no
pgroonga extension — such a test would need the `to_tsvector` arm, and
would have to put the flag
back). Without it the next author copying `WorkflowResourceSpec`'s
pattern re-adds the leak.
**Why a second file is in the diff.** `DatasetSearchQueryBuilderSpec`'s
header paragraph carried a
standing instruction — every keyword assertion in that spec must stay
branch-independent — and
justified it by asserting this leak as fact: that `DatasetResourceSpec`
and `WorkflowResourceSpec`
"both set it and neither restores it", and that an assertion on
`pgroonga_condition` "would pass solo
and fail in a full-module run". This PR falsifies the first half for
`DatasetResourceSpec` and the
second half outright. The instruction is still right, so the paragraph
now justifies it by the flag
being JVM-global mutable state that any suite in the run may write, and
states precisely which parts
of a rendered predicate survive onto both arms: the `coalesce(...) || '
' || coalesce(...)` expression
(built at `FulltextSearchQueryUtils:49-51`, before the `if`, and
embedded verbatim by either arm) and
each individual keyword token — but *not* their joining, which the two
arms render differently (test
5 below). Nothing else in that file changed — no assertion, no other
comment, no reformatting.
**What this PR does not do.** It does not touch `WorkflowResourceSpec`,
which genuinely needs the
`false` arm (it runs real keyword searches against the embedded
Postgres) and still leaks it; that is
a separate change, #8404, which restores the flag there rather than
deleting the write. It does not touch `src/main` — `usePgroonga` remains
a public mutable `var`. It
does not add or rename a test, and it does not change any assertion
anywhere.
### Any related issues, documentation, discussions?
Closes #8399
### How was this PR tested?
Every number below was read out of
`amber/target/test-reports/TEST-*.xml`, not from sbt's console
summary. Local, Windows, Java 17, module `WorkflowExecutionService`.
`1cbe857007` is the base commit.
**1. The suite stays green.** `testOnly ...file.DatasetResourceSpec`:
`tests="4" failures="0" errors="0"`.
**2. The flag read is unreachable from this suite — measured, not just
argued.** Temporarily armed
the read site in `src/main` (`if ({ sys.error("READ REACHED");
usePgroonga })`, reverted afterwards)
and ran the suite together with a control that does reach the read:
| suite | XML | meaning |
| --- | --- | --- |
| `DatasetResourceSpec` | `tests="4" failures="0"` | none of its four
tests reaches the read |
| `FulltextSearchQueryUtilsSpec` | `tests="14" failures="3"` | the probe
is armed; exactly its three flag-reading tests died |
**3. The leak is real and the deletion removes it — same invocation,
pinned order.** sbt gives
separate `testOnly` invocations fresh classloaders, so the probe puts
both suites in one invocation
and pins their order with a `Suites` subclass that overrides
`runNestedSuites` to construct each
nested suite immediately before running it (sbt's own
ScalaTest-framework semantics; `Suites(a, b)`
would evaluate both constructors up front).
| tree | printed before / after `DatasetResourceSpec` ran | observer
suite |
| --- | --- | --- |
| `1cbe857007` | `true` / `false` | FAILURE, `false was not equal to
true` |
| this branch | `true` / `true` | `tests="5" failures="0"` |
Control, so the observer is not vacuously red on base: run alone in its
own invocation on
`1cbe857007` it is `tests="1" failures="0"` — the default really is
`true`, and the `false` came from
`DatasetResourceSpec`.
**4. The downstream arm switch, and that it turns nothing red.** Same
pinned order
(`DatasetResourceSpec` then `DatasetSearchQueryBuilderSpec`, one
invocation), the only variable being
this file:
| tree | flag observed after the subject | arm that selects (test 5) |
downstream result |
| --- | --- | --- | --- |
| `1cbe857007` | `false` | `to_tsvector`/`to_tsquery` | `tests="28"
failures="0"` |
| this branch | `true` | `pgroonga_condition` | `tests="28"
failures="0"` |
That is the point of the change — downstream suites move back onto the
production arm — and it costs
nothing, because those assertions are branch-independent.
**5. Which parts of a rendered predicate are actually arm-independent.**
A throwaway spec rendered
`getFullTextSearchFilter` on both arms and dumped the SQL
(`DSL.using(POSTGRES).renderInlined`, no DB
needed):
| keywords | `usePgroonga = true` | `usePgroonga = false` |
| --- | --- | --- |
| `["alpha"]` | `... &@~ pgroonga_condition('alpha', ...)` |
`to_tsvector('english', ...) @@ to_tsquery('english', 'alpha')` |
| `["alpha", "beta"]` | `... pgroonga_condition('alpha beta', ...)` |
two predicates AND-ed, `to_tsquery('english', 'alpha')` and `... 'beta'`
|
| `["alpha beta"]` | `... pgroonga_condition('alpha beta', ...)` | `...
@@ to_tsquery('english', 'alpha & beta')` |
The `COALESCE(name, '') || ' ' || COALESCE(description, '')` expression
and each individual token
appear on both arms; the joined string `alpha beta` appears only on the
`true` arm. Asserted as such
(`tests="4" failures="0"`), which is what licenses the wording in
`DatasetSearchQueryBuilderSpec`'s
paragraph. And the spec's existing assertions really are
arm-independent: pinning the flag to each
arm and running it gives `tests="24" failures="0"` both ways.
> Correction, so nobody carries the old sentence forward: an earlier
revision of that paragraph (and
> of this PR body) said the tokens "render identically on either arm".
Review caught it and the table
> above is why it was wrong — only *individual* tokens and the
`coalesce` expression survive both
> arms, not a joined multi-token string. The shipped paragraph now says
exactly that. Nothing in the
> spec asserted on a joined string, so no test changed.
**6. No regression.** `AMBER_TEST_FILTER=skip-integration
WorkflowExecutionService/test`, run on the
base commit first and then on this branch in the same worktree. Counting
`<failure>`, `<error>` and
`<skipped>` children of `<testcase>` separately, because the distinction
matters here:
| | report files | tests | `<failure>` | `<error>` | `<skipped>` |
| --- | --- | --- | --- | --- | --- |
| `1cbe857007` | 195 | 2303 | 84 | 1 | 1 |
| this branch | 195 | 2303 | 84 | 1 | 1 |
The two non-pass identity lists are byte-identical (`diff` is empty).
The 85 failures/errors are all
pre-existing local-environment failures — `ResultExportServiceSpec` 17,
`DataProcessingSpec` 16,
`ExecutionStatsServiceSpec` 12, `ExecutionResultServiceSpec` 11,
`SyncExecutionResourceSpec` 8,
`InputPortMaterializationReaderThreadSpec` 8, `PveResourceSpec` 6,
`ReconfigurationSpec` 2,
`PauseSpec` 2, and one each in `WorkflowExecutionServiceSpec`,
`GitVersionControlLocalFileStorageSpec` and `DefaultCostEstimatorSpec`
(that last is a
construction-time abort) — none of them in the dashboard search path
this PR touches. The single
`<skipped>` is `NetworkOutputBufferSpec`'s `pendingUntilFixed` test,
which is not a failure at all.
> Correction: an earlier revision of this body reported "86 non-pass
identities" with a tail of "8
> singletons/pairs". Review could not reproduce 86 and measured 85. Both
measurements were right about
> the XML — 86 was 85 failures/errors plus that one `pendingUntilFixed`
`<skipped>` row, silently
> lumped in with the failures. The table above separates them. It was a
bad count, not a flake.
Worth recording, because it is why the identity diff alone is not
sufficient evidence: sbt's suite
order is not stable across invocations of the same command. In the base
run
`DatasetSearchQueryBuilderSpec` ran 1st of 195 and `DatasetResourceSpec`
54th — so the downstream
spec happened to run *before* the leak and saw `true` anyway; in the
branch run they were 141st and
102nd. Tests 3-5 are the ordered evidence; the module runs only show
that nothing else moved.
**7. Lint.** `WorkflowExecutionService/scalafmtCheck`,
`WorkflowExecutionService/Test/scalafmtCheck`
and `WorkflowExecutionService/scalafixAll --check` all exit 0, the last
with its cache cleared so it
really re-scanned both changed files (`Running scalafix on 274 Scala
sources` / `on 209 Scala
sources`; the one warning it prints is pre-existing, in
`OutputManagerSpec`). scalafix is the gate
that matters here: each deletion orphans an import.
### Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Code (Opus 5)
---------
Signed-off-by: Xinyuan Lin <[email protected]>
Co-authored-by: Copilot Autofix powered by AI
<[email protected]>
---
.../dashboard/DatasetSearchQueryBuilderSpec.scala | 25 +++++++++++++---------
.../dashboard/file/DatasetResourceSpec.scala | 19 +++++++---------
2 files changed, 23 insertions(+), 21 deletions(-)
diff --git
a/amber/src/test/scala/org/apache/texera/web/resource/dashboard/DatasetSearchQueryBuilderSpec.scala
b/amber/src/test/scala/org/apache/texera/web/resource/dashboard/DatasetSearchQueryBuilderSpec.scala
index d0e3055966..51028942c0 100644
---
a/amber/src/test/scala/org/apache/texera/web/resource/dashboard/DatasetSearchQueryBuilderSpec.scala
+++
b/amber/src/test/scala/org/apache/texera/web/resource/dashboard/DatasetSearchQueryBuilderSpec.scala
@@ -111,16 +111,21 @@ import scala.jdk.CollectionConverters._
* `WorkflowExecutionService` a test->test dependency on `DAO` and `Auth`
only, so workflow-core's
* test tree is not on this module's test classpath.
*
- * The keyword tests RENDER a full-text predicate (they do not fetch one),
which does read the
- * JVM-global `FulltextSearchQueryUtils.usePgroonga` and emits whichever arm
it currently selects:
- * `pgroonga_condition(...)` when this suite runs alone, the
`to_tsvector`/`to_tsquery` arm if
- * `DatasetResourceSpec` or `WorkflowResourceSpec` ran earlier in this JVM
and left the global
- * `false` (both set it and neither restores it; amber has no `Test / fork`).
This suite therefore
- * neither touches nor restores that global, and every keyword assertion here
is deliberately
- * branch-independent: the tokens themselves and the `coalesce(...) || ' ' ||
coalesce(...)`
- * expression are built at `FulltextSearchQueryUtils:49-51`, *before* the `if
(usePgroonga)`.
- * Anything added here must keep that property — an assertion on
`pgroonga_condition` would pass
- * solo and fail in a full-module run.
+ * The keyword tests RENDER a full-text predicate (they do not fetch one),
and rendering reads the
+ * JVM-global `FulltextSearchQueryUtils.usePgroonga`: the
`pgroonga_condition(...)` arm while it
+ * holds `true`, the `to_tsvector`/`to_tsquery` arm while it holds `false`.
That flag is a plain
+ * mutable `var` and amber has no `Test / fork`, so its value here is
whatever the suites sharing
+ * this JVM have left it at — not something this spec controls or should
assume. This suite
+ * therefore neither touches nor restores it, and every keyword assertion
here is deliberately
+ * branch-independent. Two things reach both arms: the `coalesce(...) || ' '
|| coalesce(...)`
+ * expression, built in `FulltextSearchQueryUtils` as `combinedFields` before
the `if (usePgroonga)`
+ * branch and embedded verbatim by either arm, and each INDIVIDUAL keyword
token. Their JOINING does
+ * not — the `true` arm space-joins the full keyword list into one literal
(rendering
+ * `pgroonga_condition('alpha beta', ...)`), while the `false` arm emits one
predicate per keyword
+ * and joins the words *inside* a keyword with ` & ` (rendering
`to_tsquery('english', 'alpha & beta')`).
+ * `to_tsquery('english', 'alpha & beta')`). So assert on individual tokens —
never on a joined
+ * multi-token string, and never on one arm's own output; either would tie
this spec's result to
+ * whichever other suites wrote the flag first.
*
* The `record.into(USER).into(classOf[User]).getEmail` in
`VersionedResourceTables.hydrate` used to
* be executed but unobservable: the dataset schema left
`UnifiedResourceSchema`'s `userEmail` at its
diff --git
a/amber/src/test/scala/org/apache/texera/web/resource/dashboard/file/DatasetResourceSpec.scala
b/amber/src/test/scala/org/apache/texera/web/resource/dashboard/file/DatasetResourceSpec.scala
index 70b8252c09..7e58489556 100644
---
a/amber/src/test/scala/org/apache/texera/web/resource/dashboard/file/DatasetResourceSpec.scala
+++
b/amber/src/test/scala/org/apache/texera/web/resource/dashboard/file/DatasetResourceSpec.scala
@@ -25,7 +25,6 @@ import org.apache.texera.dao.jooq.generated.enums.UserRoleEnum
import org.apache.texera.dao.jooq.generated.tables.pojos.User
import
org.apache.texera.web.resource.dashboard.DashboardResource.SearchQueryParams
import
org.apache.texera.web.resource.dashboard.user.dataset.DatasetResource.DashboardDataset
-import org.apache.texera.web.resource.dashboard.{FulltextSearchQueryUtils}
import org.apache.texera.web.resource.dashboard.DatasetSearchQueryBuilder
import org.scalatest.flatspec.AnyFlatSpec
import org.apache.texera.dao.jooq.generated.tables.daos.{UserDao, DatasetDao,
DatasetUserAccessDao}
@@ -33,7 +32,6 @@ import
org.apache.texera.dao.jooq.generated.enums.PrivilegeEnum
import org.apache.texera.dao.jooq.generated.tables.pojos.{Dataset,
DatasetUserAccess}
import org.scalatest.{BeforeAndAfterAll, BeforeAndAfterEach}
import java.time.OffsetDateTime
-import java.util
import
org.apache.texera.web.resource.dashboard.SearchQueryBuilder.DATASET_RESOURCE_TYPE
class DatasetResourceSpec
@@ -96,7 +94,14 @@ class DatasetResourceSpec
override protected def beforeAll(): Unit = {
initializeDBAndReplaceDSLContext()
- FulltextSearchQueryUtils.usePgroonga = false // disable pgroonga
+ // `FulltextSearchQueryUtils.usePgroonga` is deliberately left at its
production default here:
+ // no test in this suite reaches the read, because both `constructQuery`
calls below pass no
+ // keywords and `getFullTextSearchFilter` returns before that read on an
empty keyword list.
+ // A keyword test added here would need the `to_tsvector` arm instead —
`MockTexeraDB` strips
+ // the full-text index block out of the DDL, so the embedded Postgres has
no pgroonga extension
+ // — and would have to set the flag and put it back: amber has no `Test /
fork`, so a value
+ // left behind here follows every suite scheduled after this one in the
same JVM.
+
// add test user directly
val userDao = new UserDao(getDSLContext.configuration())
userDao.insert(ownerUser)
@@ -124,14 +129,6 @@ class DatasetResourceSpec
shutdownDB()
}
- private def getKeywordsArray(keywords: String*): util.ArrayList[String] = {
- val keywordsList = new util.ArrayList[String]()
- for (keyword <- keywords) {
- keywordsList.add(keyword)
- }
- keywordsList
- }
-
private def assertSameDataset(a: Dataset, b: DashboardDataset): Unit = {
assert(a.getName == b.dataset.getName)
}