# request-lifecycle (from missing_doc)

> **STATUS**: ~~INTEGRATO~~
>
> - Integrato in: `specifications/02_server_foundation/04_dispatcher.md`
> - **PUÒ ESSERE ELIMINATO** dopo verifica finale

---

## Source: initial_specifications/interview/answers/C-request-lifecycle.md

**Date**: 2025-12-13
**Status**: Verified

There is a **logical request** (`BaseRequest`) that materializes into:

- `HttpRequest` - native HTTP request (ASGI scope)
- `WsxRequest` - pseudo-request from WSX message (WebSocket/NATS)

The handler always sees `BaseRequest` with a uniform interface.

```text
1. Request arrives (HTTP/WS/NATS)
   │
2. Request creation (HttpRequest or WsxRequest)
   │  - Server generates internal ID (UUID)
   │  - request.server = reference to server (dual relationship)
   │
3. Registration in RequestRegistry
   │  - registry[request.id] = request
   │
4. Dispatch to handler (via Router)
   │
5. Handler processes, produces Response
   │
6. Send Response
   │  - For WS/NATS: response carries the same correlation ID from client (if present in data)
   │
7. De-registration from RequestRegistry
   │  - del registry[request.id]
```

- **`request.id`**: Internal ID generated by server (UUID), used by registry
- **Client ID** (optional): if client sends a correlation ID, it travels in request data, not as registry ID

- In registry → in progress
- Out of registry → completed

Additional info (timestamp, duration, etc.) obtained by querying the request itself.

1. **Load snapshot**: know what the server is processing in real time
2. **Request ID as global identifier**: key for correlating logging, cache, metrics
3. **WS/NATS correlation**: associate response with pending request
4. **Lifecycle**: manage timeout, cancellation

