[GH] (texera/gh-readonly-queue/main/pr-5554-2b9add956c9e63c3c4f6e717221a0c5e33e54875): Workflow run "Required Checks" failed!

[GitBox <gi...@apache.org>]

The GitHub Actions job "Required Checks" on texera.git/gh-readonly-queue/main/pr-5554-2b9add956c9e63c3c4f6e717221a0c5e33e54875 has failed.
Run started by GitHub user aglinxinyuan (triggered by aglinxinyuan).

Head commit for run:
2c304759da7dcbf79c030f6b203597ca4c17b6ac / Xinyuan Lin <xi...@uci.edu>
test(amber): add unit test coverage for EmptyReplayLogger and ReplayLogGenerator (#5554)

### What changes were proposed in this PR?

Pin behavior of two previously-uncovered modules in
`engine/architecture/logreplay`. No production-code changes.

| Spec | Source class | Tests |
| --- | --- | --- |
| `EmptyReplayLoggerSpec` | `EmptyReplayLogger` | 9 |
| `ReplayLogGeneratorSpec` | `ReplayLogGenerator` | 10 |

Both spec files follow the `<srcClassName>Spec.scala` one-to-one
convention.

**Behavior pinned — `EmptyReplayLogger`**

| Surface | Contract |
| --- | --- |
| `drainCurrentLogRecords(step)` | returns an empty
`Array[ReplayLogRecord]` regardless of `step` (positive, zero,
`Long.MaxValue`, negative); returns a non-null array; element type is
`ReplayLogRecord` (compile-time enforced) |
| `markAsReplayDestination` | no-op for any
`EmbeddedControlMessageIdentity`; does not accumulate state |
| `logCurrentStepWithMessage` | no-op for any `(step, channelId, msg)`
triple, including `msg = None` and 100 successive calls |
| Trait conformance | usable through the `ReplayLogger` interface |

**Behavior pinned — `ReplayLogGenerator.generate`**

| Surface | Contract |
| --- | --- |
| `getStorage(None)` (EmptyRecordStorage) | returns `(empty queue, empty
queue)` |
| empty `VFSRecordStorage` file | returns `(empty queue, empty queue)` |
| only `ProcessingStep` records | enqueues all into the steps queue,
preserving insertion order |
| only `MessageContent` records | enqueues all into the messages queue,
preserving insertion order |
| interleaved steps + messages | partitions correctly by type,
preserving per-type order |
| `ReplayDestination(id)` matching `replayTo` | short-circuits — records
after the cut are NOT enqueued |
| `ReplayDestination(id)` NOT matching `replayTo` | is silently skipped,
iteration continues |
| multiple matching `ReplayDestination` | stops at the FIRST one |
| unknown record type (e.g. `TerminateSignal`) | throws
`RuntimeException` with a diagnostic message |

**Notes**

While writing `ReplayLogGeneratorSpec` I discovered a **production
stream-leak** in `ReplayLogGenerator.generate`: when it hits the
matching `ReplayDestination` it short-circuits via a non-local `return`,
leaving the `SequentialRecordReader`'s underlying `Input` stream open.
On Windows the leaked file handle blocks subsequent temp-dir deletion.
The spec's `cleanup` helper tolerates the resulting
`FileSystemException` so the case still passes; the real fix is at the
source and is out of scope for a test-coverage PR (will file a follow-up
issue).

`ReplayLogGeneratorSpec` uses a temp-dir-backed
`VFSRecordStorage[ReplayLogRecord]` and the production
`AmberRuntime.serde` (suite-local `ActorSystem` injected via reflection,
torn down in `afterAll`) — same harness pattern as
`CheckpointSubsystemSpec` / `ClientEventSpec` / `VFSRecordStorageSpec`.

### Any related issues, documentation, discussions?

Closes #5550.

### How was this PR tested?

Pure unit-test additions; verified locally with:

- `sbt "WorkflowExecutionService/testOnly
org.apache.texera.amber.engine.architecture.logreplay.EmptyReplayLoggerSpec
org.apache.texera.amber.engine.architecture.logreplay.ReplayLogGeneratorSpec"`
— 19 tests, all green
- `sbt scalafmtCheckAll` — clean
- CI to confirm

### Was this PR authored or co-authored using generative AI tooling?

Generated-by: Claude Code (Sonnet 4.5)

Report URL: https://github.com/apache/texera/actions/runs/27581267433

With regards,
GitHub Actions via GitBox