[feature]: RFQ Persistence Analysis Report: Current Durable State, Ephemeral State, and Gaps

Summary

This report captures RFQ-domain persistence as implemented today, highlights gaps, and proposes follow-up work. The goal is to establish a clear baseline before further schema or lifecycle changes.

Why this matters

• Restarts preserve only part of RFQ behavior.
• Missing durability in key RFQ paths limits observability and operational confidence.
• We need clear separation between intentionally ephemeral state and accidental durability gaps.

Current RFQ persistence map

Persisted today

• Accepted quote policies (buy/sell accepts that become enforceable RFQ policies).
• RFQ-linked forwarding history (open/settle/fail lifecycle data for routed HTLCs).

Not persisted today

• Rejected quotes.
• Invalid-quote validation outcomes.
• Peer-accepted quote runtime caches.
• In-flight request/session matching state.
• Runtime offer books and HTLC tracking caches.

Gap analysis

Gap 1: Rejections and invalid-quote outcomes are not durable

Impact:

• Loss of post-mortem data for failed negotiations after restart.
• Limited visibility into pricing/qualification failures over time.

Recommendation:

• Persist lightweight RFQ decision events (reject/invalid) with TTL-based retention.

Gap 2: In-flight RFQ session/request state is restart-fragile

Impact:

• Pending request/response correlation can be lost on restart.
• Operational inconsistency during rolling restarts or crashes.

Recommendation:

• Add short-lived durable in-flight session state with expiry and startup reconciliation.

Gap 3: Peer-accepted quote cache is memory-only

Impact:

• Quotes that are still valid can become unavailable after restart.
• Reduced continuity for quote usage windows.

Recommendation:

• Persist peer-accepted quotes with strict expiry-driven retention.

Gap 4: Offer book persistence is undefined

Impact:

• Behavior depends on external re-registration and startup ordering.
• Potentially surprising operator experience after restart.

Recommendation:

• Make an explicit product decision: either persist and replay offers, or document this as intentionally ephemeral.

Suggested implementation priorities

Priority 1

• Persist rejection + invalid decision events (with retention policy).

Priority 2

• Persist in-flight request/session state to improve restart safety.

Priority 3

• Persist peer-accepted quote cache until quote expiry.

Priority 4

• Decide and document offer persistence semantics (durable vs ephemeral by design).

Proposed next steps

1. Confirm which non-durable states are intentional vs gaps.
2. Split follow-up implementation issues by persistence area and priority.
3. Define retention + migration strategy up front.
4. Add restart-focused integration tests for any newly durable state.

Acceptance criteria for closing this issue

• RFQ persistence baseline documented and agreed.
• Intentional ephemeral states explicitly documented.
• Follow-up issues created for approved persistence additions.