FlowReactor Backlog

Support multiple "Application" nodes (each representing a different microservice) - Model inter-service communication, not just "my app → dependencies" - Visualize which service calls which - Why: Real distributed systems have many services; FlowReactor currently models only one app's perspective

Visual heatmap of response times across all HTTP/messaging nodes over time - Highlights p50, p95, p99 - Identifies which dependency is causing slowness - Why: Latency issues in distributed systems are hard to trace; a heatmap makes the slow node obvious at a glance

Dedicated tab for messages that were dead-lettered (nacked → DLQ) - Shows: original message, error reason, timestamp - Replay button: re-inject a dead-lettered message - Why: DLQ investigation is a common pain point; currently you'd have to tail actual RabbitMQ management UI

For messaging nodes (RabbitMQ, SQS, Kafka): show current queue depth, message backlog - Inspect individual queued messages before delivery - Manually publish test messages from UI - Why: "What's in the queue right now?" is a fundamental debugging question for async systems

Filter by node, event type, time range - Free-text search across payloads - Already has event type enum; just needs filter UI - Why: In a busy run with many nodes, the timeline is unreadable without filtering

Expand a timeline event to see the full request/response body - Syntax-highlighted JSON viewer - Search within payload - Currently: payload summary exists; full body is shown inline but limited - Why: Debugging is impossible without seeing exact payloads

Live counters per node: request count, error rate, avg latency, throughput (req/s) - Sparkline chart for the current run - Shown in the node inspector (new "Metrics" tab) - Why: Developers want to see "is my Redis hit rate good?" not just individual events

flowreactor run --project myproject.json — run a simulation headlessly - Outputs structured JSON events to stdout - CI-friendly: non-zero exit on unexpected faults or connection failures - Config overrides via env vars (FLOWREACTOR_REDIS_PORT etc.) - Why: Teams want to run FlowReactor in CI pipelines alongside their integration tests

Pre-built node configurations for common patterns - Examples: "Stripe Webhook", "AWS SNS Fan-Out", "Email OTP Flow", "Redis Session Cache" - Blueprints drop in a pre-wired sub-graph (multiple nodes + connections) - Why: Removes boilerplate for common distributed system patterns; better than blank-slate every time

Named fault profiles: "Normal", "Degraded", "Partial Outage", "Full Outage" - Chaos mode: apply a profile to ALL nodes simultaneously with one click - Profile saved per-project - Why: Quickly switch between "everything works" and "dependency X is down" scenarios without editing each node individually