valkyrjaio / valkyrja-java / 30594384896

100%

push

github

[Grpc] fix: Park the outbound writer instead of discarding a wait result (#85)

# Description

Follow-up to #82, which added the gRPC outbound flow-control gate. That
gate held the writing thread
on a `Condition` with a bounded timeout, and discarded the `boolean` the
timed `await` returns.
Discarding it was deliberate — whether the wait was signaled or timed
out tells the gate nothing,
because the loop re-reads `ServerCall.isReady()`, which is the
transport's own authoritative answer
either way. #82 recorded that reasoning as a narrow SpotBugs exclusion.

Suppressing it was the wrong call. SonarCloud flagged the same line
independently as `java:S899` and
classifies it as a reliability **bug**, so the quality gate went red on
the merged change. Two
analyzers reaching for the same line is a signal to restructure the
code, not to add a second
suppression next to the first.

So the gate now parks the writer directly instead of waiting on a
condition variable:

- `LockSupport.parkNanos` / `LockSupport.unpark` both return `void`, so
there is no status value to
discard and nothing for either analyzer to flag. The primitive also
states the intent more
plainly than a condition variable did — the gate holds one thread until
the transport is writable
or a bounded interval elapses, which is exactly what park/unpark is for.
It needs no lock, so the
  `ReentrantLock` and its `Condition` are gone.
- The parked writer is published through an `AtomicReference<@Nullable
Thread>` that `signal()`
reads to unpark it. A plain `volatile Thread` field would work, but
Sonar's `S3077` flags
`volatile` on a non-primitive field and prescribes exactly this;
`AtomicReference` is also already
  the idiom used for cross-thread publication in `WorkerGrpc`.

Behavior is unchanged. Each park is still bounded, so a signal that
races the park costs one
interval rather than stranding the writer, and the loop still re-reads
the transport regardless of
why the park ended — which is what ke... (continued)

1925 of 1925 branches covered (100.0%)

Branch coverage included in aggregate %.

13 of 13 new or added lines in 1 file covered. (100.0%)

7038 of 7038 relevant lines covered (100.0%)

4.33 hits per line