laserninja opened a new issue, #12049: URL: https://github.com/apache/gravitino/issues/12049
## Describe the proposal The Iceberg REST spec defines an optional `Idempotency-Key` header (UUIDv7) on mutation endpoints. When present, the server must return the original response for replayed keys instead of re-executing the operation, preventing duplicate side-effects from client retries. This epic covers the full implementation of idempotency support in Gravitino's Iceberg REST server, including multi-node consistency and node-failure resilience. Key concerns addressed: - **Multi-node deployments**: Retries may hit different nodes behind a load balancer; a shared durable store (JDBC-backed) ensures all nodes see the same idempotency state - **Node failure resilience**: DB-backed records survive crashes; TTL-based expiry handles abandoned reservations - **Configurable storage backends**: In-memory (single-node/dev) and JDBC-backed (production) - **Spec compliance**: UUIDv7 validation, `idempotency-key-lifetime` advertised in `GET /v1/config` Reference: [apache/polaris#3205](https://github.com/apache/polaris/pull/3205) (database-backed IdempotencyStore) Design document: `design-docs/iceberg-idempotency-key.md` Supersedes #10683. ## Task list - [ ] Design document review and approval - [ ] IdempotencyStore SPI interface, IdempotencyRecord model, and InMemoryIdempotencyStore - [ ] JdbcIdempotencyStore using Gravitino's relational backend (H2/MySQL/PostgreSQL) - [ ] Header handling, replay logic, and mutation endpoint integration - [ ] Advertise `idempotency-key-lifetime` in `GET /v1/config` - [ ] Unit and integration tests -- 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]
