feat(supplier,gateway,buyer): N-slot chat suppliers + entry-ticket settle mode
Two structural fixes for demo concurrency (3 single-slot suppliers thrashed
under Open WebUI's ~3 conversations per message):
Multi-slot suppliers (MAX_CHAT_SESSIONS, default 1):
- SupplierState is now capacity-aware: a Set of active escrow refs with
free-until-full status semantics, ref-scoped release(ref) (also fixes the
latent bug where handler catch-alls released another request's slot), and
a walletMutex serializing every wallet-spending chain op — Claim, Submit,
and wallet-health consolidation queue instead of racing the single
working/collateral UTxO. /status gains active_sessions/max_sessions.
Entry-ticket settle mode (CHAT_SETTLE_MODE=ticket, default full, both sides):
- The buyer's escrow post at session open is the ONLY chain op. The supplier
verifies the Open escrow as an entry ticket but never Claims/Submits
(/v1/chat/start → {status:"ticket"}; /v1/chat/end → receipt-less
{status:"ended"}); no hard-cap timer, so sessions may outlive deliver_by.
Used tickets can't reopen sessions (records retained; 409 session_exists).
- Buyer SDK: startChat/endChat are settle-mode aware, driven by the
supplier's response — mixed-mode rollout windows settle correctly.
- Gateway: ticket closes bill cost 0; the sweeper Reclaims Open tickets
after deliver_by WITHOUT closing live sessions (the conversation and its
affinity mirror survive their reclaimed ticket), gates reclaims on
deliver_by, and keeps an in-process settled-refs memory so terminal
indexer rows aren't retried every sweep forever.
Deployment (kimi-chat trio + gateway): ticket mode, 8 slots per supplier,
idle policy gateway 10 min / supplier 15 min (fixes the inversion where the
supplier idle-closed before the gateway janitor).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
@@ -38,6 +38,13 @@ services:
|
||||
# frontend's "API Keys" page (served from marketplace.vector…) POSTs to
|
||||
# /signup here. Comma-separated; empty disables CORS entirely.
|
||||
GATEWAY_CORS_ORIGINS: https://marketplace.vector.apexfusion.org
|
||||
# Ticket mode: the escrow post at session open is the only chain op;
|
||||
# the sweeper reclaims Open escrows after deliver_by. Must match the
|
||||
# kimi-chat suppliers' CHAT_SETTLE_MODE.
|
||||
CHAT_SETTLE_MODE: ticket
|
||||
# Demo janitor closes idle sessions BEFORE the suppliers' 15 min
|
||||
# CHAT_IDLE_TIMEOUT_MS backstop.
|
||||
DEMO_SESSION_IDLE_MS: "600000"
|
||||
volumes:
|
||||
- gateway-mainnet-data:/repo/data/gateway
|
||||
healthcheck:
|
||||
|
||||
@@ -40,7 +40,9 @@ services:
|
||||
OPENAI_TIMEOUT_MS: "300000"
|
||||
# 2.5 min idle end: single-slot suppliers must free up quickly for the
|
||||
# shared demo endpoint (the gateway transparently reopens on next turn).
|
||||
CHAT_IDLE_TIMEOUT_MS: "150000"
|
||||
CHAT_IDLE_TIMEOUT_MS: "900000"
|
||||
CHAT_SETTLE_MODE: ticket
|
||||
MAX_CHAT_SESSIONS: "8"
|
||||
PORT: "8080"
|
||||
# Enable LiveOgmiosProvider so Claim/Submit actually broadcast.
|
||||
LIVE_CHAIN: "1"
|
||||
|
||||
@@ -40,7 +40,9 @@ services:
|
||||
OPENAI_TIMEOUT_MS: "300000"
|
||||
# 2.5 min idle end: single-slot suppliers must free up quickly for the
|
||||
# shared demo endpoint (the gateway transparently reopens on next turn).
|
||||
CHAT_IDLE_TIMEOUT_MS: "150000"
|
||||
CHAT_IDLE_TIMEOUT_MS: "900000"
|
||||
CHAT_SETTLE_MODE: ticket
|
||||
MAX_CHAT_SESSIONS: "8"
|
||||
PORT: "8080"
|
||||
# Enable LiveOgmiosProvider so Claim/Submit actually broadcast.
|
||||
LIVE_CHAIN: "1"
|
||||
|
||||
@@ -52,7 +52,9 @@ services:
|
||||
# 2.5 min idle end (supplier Submits the transcript): single-slot
|
||||
# suppliers must free up quickly for the shared demo endpoint (the
|
||||
# gateway transparently reopens a session on the next turn).
|
||||
CHAT_IDLE_TIMEOUT_MS: "150000"
|
||||
CHAT_IDLE_TIMEOUT_MS: "900000"
|
||||
CHAT_SETTLE_MODE: ticket
|
||||
MAX_CHAT_SESSIONS: "8"
|
||||
PORT: "8080"
|
||||
# Enable LiveOgmiosProvider so Claim/Submit actually broadcast.
|
||||
LIVE_CHAIN: "1"
|
||||
|
||||
Reference in New Issue
Block a user