# ListApprovalRequestsForRequester

## Overview

ListApprovalRequestsForRequester is the requester-side counterpart to the `listApprovalRequestsForApprover` My Inbox query: it returns the `ApprovalRequest` rows the given user originated (`requesterId = userId`), narrowed by an optional `status` filter. Its primary purpose is to surface the requests a requester must act on after a send-back.

## Business Rules

- Accepts `userId` as a required input (matched against `ApprovalRequest.requesterId`)
- Accepts an optional `status` filter that narrows by `ApprovalRequest.status`; defaults to `REVISION_REQUESTED` when omitted
- Accepts standard pagination inputs (`limit`, `offset`, `orderBy`, `orderDirection`); `limit` defaults to the framework `DEFAULT_PAGE_SIZE`
- Default ordering when no `orderBy` is supplied is `createdAt DESC` so the freshest request surfaces first
- Returns a paginated result `{ items, hasNextPage }`; an empty `items` array is not an error

## Process Flow

```mermaid
flowchart TD
    A[Receive userId and optional status, default REVISION_REQUESTED,<br/>plus optional pagination inputs] --> B[SELECT ApprovalRequest<br/>WHERE requesterId = userId<br/>AND status matches input]
    B --> C[ORDER BY orderBy orderDirection<br/>default request.createdAt DESC]
    C --> D[LIMIT limit + 1 OFFSET offset]
    D --> E[Return paginated result &lcub; items, hasNextPage &rcub;]
```

## External Dependencies

- None

## Error Scenarios

- None — an empty result is not an error

## Test Cases

- returns the requester's REVISION_REQUESTED requests by default
- accepts a non-default status (e.g. PENDING) to surface the requester's in-flight requests
- returns an empty array when the user has no matching requests
- returns rows ordered by createdAt DESC
