The GitHub Actions job "Build and push images" on texera.git/main has failed. Run started by GitHub user bobbai00 (triggered by bobbai00).
Head commit for run: 75b46197d3584e0f211d5d3211bef571f5c61e9c / Xinyuan Lin <[email protected]> test(amber): add unit test coverage for record-storage cluster (#5447) ### What changes were proposed in this PR? Pin behavior of three previously-uncovered modules in `engine/common/storage` that sit on the checkpoint / fault-tolerance hot path via `SequentialRecordStorage.getStorage(...)`. No production-code changes. | Spec | Source class | Tests | | --- | --- | --- | | `EmptyRecordStorageSpec` | `EmptyRecordStorage` | 11 | | `VFSRecordStorageSpec` | `VFSRecordStorage` | 9 | | `SequentialRecordStorageSpec` | `SequentialRecordStorage` (abstract + companion) | 9 | All three spec files follow the `<srcClassName>Spec.scala` one-to-one convention. **Behavior pinned** | Surface | Contract | | --- | --- | | `SequentialRecordStorage.getStorage(None)` | dispatches to `EmptyRecordStorage` | | `SequentialRecordStorage.getStorage(Some(file://…))` | dispatches to `VFSRecordStorage` and the returned instance round-trips a record | | `SequentialRecordWriter` / `SequentialRecordReader` | round-trip a sequence of records through the size-prefixed binary frame; the reader's `inputStreamGen` thunk supports re-reading the same byte stream | | `SequentialRecordStorage.fetchAllRecords` | yields the underlying iterator's records in order (and `Iterable.empty` when nothing was written) | | `VFSRecordStorage` constructor | auto-creates the target folder; leaves an existing folder + contents intact | | `VFSRecordStorage.getWriter` / `getReader` | round-trip records through a local `file://` URI; produce empty iterator when the file has no records; multiple files under the same folder do not cross-pollinate | | `VFSRecordStorage.deleteStorage` | removes the on-disk folder created by the constructor | | `VFSRecordStorage.containsFolder` | distinguishes existing folder vs. existing file vs. missing entry | | `EmptyRecordStorage.containsFolder` | always returns `false` regardless of folder name | | `EmptyRecordStorage.deleteStorage` | is a safe no-op (idempotent) | | `EmptyRecordStorage.getReader` | yields zero records for any fileName; successive `getReader` calls produce independent iterators | | `EmptyRecordStorage.getWriter` | returns a writer whose `flush()` / `close()` work without `writeRecord` having been called; a second writer is unaffected by closing the first | **Notes** - The `hdfs://` dispatch branch of `getStorage` is deliberately left out — `HDFSRecordStorage`'s constructor calls `FileSystem.get`, which can block on DNS / network and is unit-test-hostile. The branch is a single line and any regression there would surface immediately in higher-level checkpoint / fault-tolerance suites that exercise `hdfs://` URIs. - The serde-touching paths (`SequentialRecordWriter.writeRecord` / `SequentialRecordReader`'s iterator) hard-code `AmberRuntime.serde`. The two specs that exercise this path (`VFSRecordStorageSpec`, `SequentialRecordStorageSpec`) own a suite-local `ActorSystem` and inject it into `AmberRuntime` via reflection, tearing it down in `afterAll` — same pattern as `CheckpointSubsystemSpec` / `ClientEventSpec`. `EmptyRecordStorageSpec` deliberately avoids `writeRecord` so it does not need the harness. ### Any related issues, documentation, discussions? Closes #5446. ### How was this PR tested? Pure unit-test additions; verified locally with: - `sbt "WorkflowExecutionService/testOnly org.apache.texera.amber.engine.common.storage.EmptyRecordStorageSpec org.apache.texera.amber.engine.common.storage.SequentialRecordStorageSpec org.apache.texera.amber.engine.common.storage.VFSRecordStorageSpec"` — 29 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/27113704522 With regards, GitHub Actions via GitBox
