DashBoard/spec.md at a275c30c0ee33a1d7239406ae98969d58d49bb76

Files

egg a275c30c0e feat(reject-history): fix silent data loss by propagating partial failure metadata to frontend

Chunk failures in BatchQueryEngine were silently discarded — `has_partial_failure` was tracked
in Redis but never surfaced to the API response or frontend. Users could see incomplete data
without any warning. This commit closes the gap end-to-end:

Backend:
- Track failed chunk time ranges (`failed_ranges`) in batch engine progress metadata
- Add single retry for transient Oracle errors (timeout, connection) in `_execute_single_chunk`
- Read `get_batch_progress()` after merge but before `redis_clear_batch()` cleanup
- Inject `has_partial_failure`, `failed_chunk_count`, `failed_ranges` into API response meta
- Persist partial failure flag to independent Redis key with TTL aligned to data storage layer
- Add shared container-resolution policy module with wildcard/expansion guardrails
- Refactor reason filter from single-value to multi-select (`reason` → `reasons`)

Frontend:
- Add client-side date range validation (730-day limit) before API submission
- Display amber warning banner on partial failure with specific failed date ranges
- Support generic fallback message for container-mode queries without date ranges
- Update FilterPanel to support multi-select reason chips

Specs & tests:
- Create batch-query-resilience spec; update reject-history-api and reject-history-page specs
- Add 7 new tests for retry, memory guard, failed ranges, partial failure propagation, TTL
- Cross-service regression verified (hold, resource, job, msd — 411 tests pass)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

2026-03-03 14:00:07 +08:00

2.1 KiB

Raw Blame History

MODIFIED Requirements

Requirement: Reject History API SHALL validate required query parameters

The API SHALL validate date parameters and basic paging bounds before executing database work.

Scenario: Missing required dates

WHEN a reject-history endpoint requiring date range is called without start_date or end_date
THEN the API SHALL return HTTP 400 with a descriptive validation error

Scenario: Invalid date order

WHEN end_date is earlier than start_date
THEN the API SHALL return HTTP 400 and SHALL NOT run SQL queries

Scenario: Date range exceeds maximum

WHEN the date range between start_date and end_date exceeds 730 days
THEN the API SHALL return HTTP 400 with error message "日期範圍不可超過 730 天"

ADDED Requirements

Requirement: Reject History API primary query response SHALL include partial failure metadata

The primary query endpoint SHALL include batch execution completeness information in the response meta field when chunks fail during batch query execution.

Scenario: Partial failure metadata in response

WHEN POST /api/reject-history/query completes with some chunks failing
THEN the response SHALL include meta.has_partial_failure: true
THEN the response SHALL include meta.failed_chunk_count as a positive integer
THEN the response SHALL include meta.failed_ranges as an array of {start, end} date strings (if available)
THEN the HTTP status SHALL still be 200 (data is partially available)

Scenario: No partial failure metadata on full success

WHEN POST /api/reject-history/query completes with all chunks succeeding
THEN the response meta SHALL NOT include has_partial_failure, failed_chunk_count, or failed_ranges

Scenario: Partial failure metadata preserved on cache hit

WHEN POST /api/reject-history/query returns cached data that originally had partial failures
THEN the response SHALL include the same meta.has_partial_failure, meta.failed_chunk_count, and meta.failed_ranges as the original response

2.1 KiB Raw Blame History