mengw15 opened a new pull request, #7502:
URL: https://github.com/apache/texera/pull/7502
### What changes were proposed in this PR?
Adds `UserActivityTrackerDbSpec`, which drives the production singleton's
**default upsert** — the one path the existing spec cannot reach, because it
injects its own `upsertFn`. Measured with JaCoCo, this takes
`UserActivityTracker.scala` from **83.9% to 100% line coverage** (the
previously
uncovered lines 151–160 were exactly `defaultUpsert`'s body).
Two tests:
- The first `markActive` for a uid writes its `USER_LAST_ACTIVE_TIME` row
through the real jOOQ upsert.
- A second `markActive` inside the cooldown window does **not** write again.
Kept in a new file so the existing `UserActivityTrackerSpec` — 22 fast,
pure-logic tests with an injected `upsertFn` — stays free of embedded
Postgres.
**Determinism.** The upsert runs on the tracker's writer thread, so the
negative
assertion ("no second write") can't rely on sleeping and hoping. Instead the
test
parks a sentinel timestamp on the row, calls `markActive` again, and then
**barriers on a different uid**: the writer is a single thread draining a
FIFO
queue, so once a later-submitted write lands, any earlier one has already
run.
The only wait is a bounded poll for a write that is guaranteed to happen.
Each
test uses its own uid, since the singleton's per-uid cooldown lives for the
life
of the JVM. Verified: 2/2 green over 3 consecutive runs, and the failure path
checked by breaking the sentinel assertion.
The issue also asks for a case where the cooldown has elapsed. The singleton
hard-codes `() => Instant.now()`, so that would need a real 5-minute wait —
it is
already covered in `UserActivityTrackerSpec` with an injected clock, so it
is not
duplicated here.
### `VFSURIFactory` is already at its reachable ceiling
The issue's other half asks for the `createNonResultVFSURI` guards. Those
are not
reachable from a test, so this PR does not touch that file. Per JaCoCo, its
only
uncovered lines are 224 and 228–229 / 234–235 / 240–241 — the three guard
`throw`s plus a default argument that is never used. Everything else,
including
the happy paths and the `decodeURI` round-trips the issue lists, is already
covered by the existing `VFSURIFactorySpec`.
`createNonResultVFSURI` is `private`, and its only two callers pass fixed
arguments:
| Guard | Only caller | Why it cannot fire |
| --- | --- | --- |
| `resourceType == RESULT` | both wrappers | they pass `RUNTIME_STATISTICS`
/ `CONSOLE_MESSAGES` |
| runtime statistics must not carry an `operatorId` |
`createRuntimeStatisticsURI` | always passes `None` |
| console messages must carry an `operatorId` | `createConsoleMessagesURI` |
always passes `Some(operatorId)` |
They are defensive invariants for a private helper: valuable if a future
caller
is added, but unreachable today. Covering them would need either a one-word
visibility change (`private` → `private[storage]`) or reflection into a
private
method; both felt out of place in a test-only PR, so I left the file alone.
Happy
to follow up with the visibility change if you'd prefer those guards pinned.
No production code was changed.
### Any related issues, documentation, discussions?
Closes #7498
### How was this PR tested?
New unit tests, run locally against embedded Postgres:
```
sbt "Auth/testOnly org.apache.texera.auth.UserActivityTrackerDbSpec"
# Tests: succeeded 2, failed 0 (3 consecutive runs, all green)
sbt "Auth/Test/scalafmtCheck" "Auth/Test/scalafix --check" # clean
sbt "Auth/jacoco" # UserActivityTracker.scala: 83.9% -> 100.0% lines
```
The failure path was verified by breaking the sentinel assertion and
confirming
the suite goes red.
### Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Code (Opus 4.8 [1M context])
--
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]
