jerryshao opened a new pull request, #12509: URL: https://github.com/apache/gravitino/pull/12509
### What changes were proposed in this pull request? Expose two additional job execution timestamps — `queuedAt` (when the job was submitted) and `startedAt` (when execution began) — through the public surface, alongside the existing `finishedAt`: - `queuedAt` — derived from the job's existing audit `createTime`; no storage schema change. - `startedAt` — a genuinely new state requiring a `job_started_at` column in `job_run_meta` (MySQL/PostgreSQL/H2 fresh-install schemas + the 1.3.0→2.0.0 upgrade scripts), following the same sentinel convention as `job_finished_at`. - `JobHandle.queuedAt()`/`startedAt()` (Java `default` methods / Python) — non-abstract, raising by default so existing external implementers don't break. - `JobDTO.queuedAt`/`startedAt`, `JobEntity.startedAtAsInstant()`, wired through `JobOperations.toDTO`, `JobInfo`, and `GenericJobHandle` (Java + Python). - `JobManager.pullAndUpdateJobStatus` stamps `startedAt` at the `QUEUED`/`CANCELLING`→`STARTED` transition, and falls back to `queuedAt` when a job reaches `SUCCEEDED`/`FAILED` without ever being observed as `STARTED` (reaching those states proves it ran). `CANCELLED` is deliberately excluded from that fallback, since a cancelled job may have been killed while still `QUEUED` and genuinely never started. - OpenAPI schema and examples updated for both fields. ### Why are the changes needed? Callers could already see when a job finished but had no way to see when it was queued or when execution actually started — useful for measuring queue wait time and execution duration. Fix: #12508 ### Does this PR introduce _any_ user-facing change? Yes: - New `queuedAt`/`startedAt` fields on the `Job` REST API response / OpenAPI schema. - New `JobHandle.queuedAt()`/`startedAt()` (Java) / `queued_at()`/`started_at()` (Python) client API. - New `job_started_at` column added to the `job_run_meta` table (fresh-install schema and upgrade script for MySQL/PostgreSQL/H2). - `JobHandle` implementers outside this repo will get defaults that raise `UnsupportedOperationException`/`NotImplementedError` unless they override the new methods. ### How was this patch tested? Unit tests across `common`, `core`, `server`, `clients/client-java`, and `clients/client-python` (DTO ser/de, `JobEntity` builder/equality, `JobManager` status-polling including the `startedAt` fallback and its `CANCELLED` exclusion, `JobOperations`/`JobPO` conversion, real SQL round-trip through H2), plus Java and Python integration tests (`JobIT`, `tests/integration/test_supports_jobs.py`) running real jobs to completion/failure/cancellation and asserting `queuedAt`/`startedAt`/`finishedAt`. -- 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]
