Description
Give retrying/failing events their own stats bucket instead of counting them as healthy in-flight work.
Problem Statement
engine-bridge/src/event-queue.ts lines 268-276: events in status='failed' with attempts < maxRetries are counted into stats.processing rather than a distinct retry bucket. During an outage where handlers are failing and retrying, operators watching the dashboard's "processing" count won't see the growing failure/retry backlog — it looks like healthy in-flight work.
Proposed Changes
Technical Implementation Scaffolding
- Target Repository: vero-core-engine
- Target Path: engine-bridge/src/event-queue.ts
- Branch Naming: fix/issue--event-queue-stats-retry-bucket
- Authority Context: Observability
Acceptance Criteria
Definition of Done
Description
Give retrying/failing events their own stats bucket instead of counting them as healthy in-flight work.
Problem Statement
engine-bridge/src/event-queue.tslines 268-276: events instatus='failed'withattempts < maxRetriesare counted intostats.processingrather than a distinct retry bucket. During an outage where handlers are failing and retrying, operators watching the dashboard's "processing" count won't see the growing failure/retry backlog — it looks like healthy in-flight work.Proposed Changes
retrying(or similar) bucket togetStats()output and stop folding failed-but-retrying events intoprocessingTechnical Implementation Scaffolding
Acceptance Criteria
getStats()reports retrying events separately from actively-processing onesDefinition of Done