fix: stop the prepared demo failure from degrading n8n integration health
The demo seed plants exactly one failed delivery (BK-H-0020) to demonstrate retry and audit. Because derive_n8n_status() counted any failure, every fresh reset pinned the n8n integration to "degraded" -- the demo showed a warning about a prop, which tells a viewer something untrue about the automation. The seeded failure now carries its own error code, demoScenarioTimeout, rather than the generic connectionError a real timeout produces. No column and no migration: last_error_code already existed, is already surfaced to the UI and is already localizable. - integration status splits failed into unexpected_failed and demo_scenario_failed; only unexpected failures may move the state. A staged failure alone leaves n8n operational. - latest_failure_at is a health signal and now ignores the staged failure; latest_demo_scenario_at reports it separately. - /api/v1/workflows exposes is_demo_scenario. The Automation page labels the run as a prepared demo scenario, explains that it is a simulated temporary failure that does not affect automation health, and offers a distinct "retry demo scenario" action. Translated in nl-BE, en-GB and fr-BE. - the carve-out stays narrow: a real failure still degrades n8n, and a genuine later failure of the same event overwrites the demo code with the real one. - the retry itself is unchanged and real: the event goes back on the outbox and the dispatcher delivers it to n8n like any other, so 19+1 becomes 20+0 only on an actual round trip. The audit records which kind of failure was retried. Tests that assert on the seeded scenario now reseed first, since earlier test files legitimately mutate the outbox and the suite shares one database. Verified locally against a real PostgreSQL 16: 181 passed, ruff clean, mypy clean (50 files), tsc clean, frontend build clean. Not deployed and not browser-verified.
This commit is contained in:
+15
-1
@@ -266,11 +266,21 @@ class N8nIntegrationStatus(BaseModel):
|
||||
dispatch_enabled: bool
|
||||
state: Literal["disabled", "unavailable", "degraded", "operational", "no_evidence"]
|
||||
pending: int
|
||||
delivering: int
|
||||
#: Every failed delivery, staged and real together -- the number a viewer sees in
|
||||
#: the run list.
|
||||
failed: int
|
||||
#: Failures that were not planted by the demo seed. This is the only failure count
|
||||
#: that may influence `state`.
|
||||
unexpected_failed: int = 0
|
||||
#: Prepared demo failures (see `app.models.outbox.DEMO_SCENARIO_ERROR_CODE`).
|
||||
#: Present so the UI can label them instead of implying the automation is broken.
|
||||
demo_scenario_failed: int = 0
|
||||
delivering: int
|
||||
succeeded: int
|
||||
latest_success_at: datetime | None
|
||||
#: Most recent *real* failure; a staged one never sets this.
|
||||
latest_failure_at: datetime | None
|
||||
latest_demo_scenario_at: datetime | None = None
|
||||
expected_workflow_count: int
|
||||
known_workflow_count: int
|
||||
workflows: list[N8nWorkflowEvidence]
|
||||
@@ -365,6 +375,10 @@ class AutomationRunOut(BaseModel):
|
||||
attempts: int
|
||||
last_error: str | None
|
||||
last_error_code: str | None
|
||||
#: True for the deliberately seeded demo failure. The UI uses this to label the run
|
||||
#: as a prepared scenario and to offer the demo retry, instead of presenting it as
|
||||
#: an unexplained production error.
|
||||
is_demo_scenario: bool = False
|
||||
occurred_at: datetime
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user