39 lines
1.6 KiB
Markdown
39 lines
1.6 KiB
Markdown
# Reflection: Backend Automation Must Reconcile The Open UI
|
|
|
|
## Trigger
|
|
|
|
The worker published monthly reports automatically, but the open page still required a person to click “刷新” before
|
|
the new version appeared.
|
|
|
|
## Expected Behavior
|
|
|
|
An automated business workflow includes both durable backend completion and automatic reconciliation of the visible
|
|
user interface. Once publication is committed, an open list should discover it without another user action.
|
|
|
|
## Actual Behavior
|
|
|
|
The page loaded monthly versions only at boot or from a refresh-button handler. Backend automation was complete, but
|
|
the UI held a stale snapshot indefinitely.
|
|
|
|
## Root Cause
|
|
|
|
- Backend completion and frontend observability were treated as separate acceptance concerns.
|
|
- The asynchronous worker cannot return its result through the original upload HTTP response.
|
|
- No polling, push channel or visibility-resume contract existed for the monthly list.
|
|
|
|
## Lesson
|
|
|
|
For asynchronous publication, acceptance must cover how an already-open client observes the committed result. Prefer a
|
|
bounded, visibility-aware synchronization mechanism that avoids overlapping requests and preserves the last good state.
|
|
|
|
## Action
|
|
|
|
- Poll only while the monthly tab/document is visible and reload immediately when it becomes active.
|
|
- Keep the last good rows on transient background errors and retry automatically.
|
|
- Remove the manual refresh control from the primary workflow.
|
|
- Verify both rendered state and actual repeated API requests.
|
|
|
|
## Promotion
|
|
|
|
Promoted to ADR-001, success criteria, business rules, architecture data flow and the Web static contract tests.
|