What problem does the new feature solve?
During repartition, region failover, or transient routing inconsistency, the frontend may see temporary write failures. In many cases, these failures are not caused by invalid requests, but because the target region is temporarily unavailable or routing/metadata has not converged yet.
Today, these writes are returned to clients as errors directly and require the clients to retry, which hurts write availability during those transition windows.
What does the feature do?
Add a retry queue in the GreptimeDB frontend to buffer write requests that fail due to transient errors, and replay them once the target region becomes available again.
The retry queue should support:
- Local buffering of retryable failed writes
- Persistence so queued requests survive frontend restarts
- Asynchronous replay after region recovery or route convergence
- Resource control, such as queue size, disk usage, retry limits, and TTL
Implementation challenges
- Retryable error classification
- Persistence format
- Idempotency, ordering and isolation
- Backpressure and limits
What problem does the new feature solve?
During repartition, region failover, or transient routing inconsistency, the frontend may see temporary write failures. In many cases, these failures are not caused by invalid requests, but because the target region is temporarily unavailable or routing/metadata has not converged yet.
Today, these writes are returned to clients as errors directly and require the clients to retry, which hurts write availability during those transition windows.
What does the feature do?
Add a retry queue in the GreptimeDB frontend to buffer write requests that fail due to transient errors, and replay them once the target region becomes available again.
The retry queue should support:
Implementation challenges