# ListLeaveRequestsByWorker

## Overview

Lists a worker's own leave requests across all statuses, so the worker can see their filing history — pending, approved, rejected, withdrawn, or mid-cancellation.

## Business Rules

- Returns all LeaveRequest rows for the given `workerId`, across every status, ordered most-recent first
- Includes both terminal (REJECTED, CANCELLED) and non-terminal (PENDING, APPROVED, CANCEL_PENDING) requests
- Paginated for workers with a long request history

**Known gap:** `workerId` is a cross-module (workforce) reference, and no `getWorker`/existence-check
query is injected into this module yet. This query does not validate that `workerId` resolves to an
existing Worker — it simply filters `LeaveRequest` by the given id, mirroring the precedent set in
`modules/workforce/command/createWorker.ts` (and `modules/scheduling/query/listRosterAssignmentsByAssignment.ts`)
of not inventing a fictitious cross-module existence check. Referential integrity for `workerId` is
enforced by the DB-level FK once the workforce Worker type is injected via `module.ts`. An unknown
`workerId` simply yields an empty page rather than a `WORKER_NOT_FOUND` error.

## Process Flow

```mermaid
flowchart TD
    A[Caller requests leave requests for a workerId] --> B[Load LeaveRequest rows for workerId]
    B --> C[Order most-recent first]
    C --> D[Paginate and return]
```

## External Dependencies

- [leave-management::LeaveRequest](../model/LeaveRequest.md) model — entity being queried
- [workforce::Worker](../../../workforce/docs/model/Worker.md) model — referenced by `workerId` (no existence check yet — see Known Gap above)

## Error Scenarios

- None — an unknown `workerId` returns an empty page (see Known Gap above)

## Test Cases

- returns a worker's requests across all statuses
- includes terminal (REJECTED, CANCELLED) requests
- includes a CANCEL_PENDING request
- orders results most-recent first
- returns an empty page for an unknown workerId