DashBoard/spec.md at 71c8102de68cf1f947388b4913fa37f534f93c14

Files

egg 71c8102de6 feat: dataset cache for hold/resource history + slow connection migration

Two changes combined:

1. historical-query-slow-connection: Migrate all historical query pages
   to read_sql_df_slow with semaphore concurrency control (max 3),
   raise DB slow timeout to 300s, gunicorn timeout to 360s, and
   unify frontend timeouts to 360s for all historical pages.

2. hold-resource-history-dataset-cache: Convert hold-history and
   resource-history from multi-query to single-query + dataset cache
   pattern (L1 ProcessLevelCache + L2 Redis parquet/base64, TTL=900s).
   Replace old GET endpoints with POST /query + GET /view two-phase
   API. Frontend auto-retries on 410 cache_expired.

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

2026-02-25 13:15:02 +08:00

2.0 KiB

Raw Blame History

MODIFIED Requirements

Requirement: Hold History page SHALL display a filter bar with date range and hold type

The page SHALL provide a filter bar for selecting date range and hold type classification. On query, the page SHALL use a two-phase flow: POST /query returns queryId, subsequent filter changes use GET /view.

Scenario: Primary query via POST /query

WHEN user clicks the query button (or page loads with default filters)
THEN the page SHALL call POST /api/hold-history/query with { start_date, end_date, hold_type }
THEN the response queryId SHALL be stored for subsequent view requests
THEN trend, reason-pareto, duration, and list SHALL all be populated from the single response

Scenario: Hold type or reason filter change uses GET /view

WHEN user changes hold_type radio or clicks a reason in the Pareto chart (while queryId exists)
THEN the page SHALL call GET /api/hold-history/view?query_id=...&hold_type=...&reason=...
THEN no new Oracle query SHALL be triggered
THEN trend, reason-pareto, duration, and list SHALL update from the view response

Scenario: Pagination uses GET /view

WHEN user navigates to a different page in the detail list
THEN the page SHALL call GET /api/hold-history/view?query_id=...&page=...&per_page=...

Scenario: Date range change triggers new primary query

WHEN user changes the date range and clicks query
THEN the page SHALL call POST /api/hold-history/query with new dates
THEN a new queryId SHALL replace the old one

Scenario: Cache expired auto-retry

WHEN GET /view returns { success: false, error: "cache_expired" }
THEN the page SHALL automatically re-execute POST /api/hold-history/query with the last committed filters
THEN the view SHALL refresh with the new data

Scenario: Department still uses separate API

WHEN department data needs to load or reload
THEN the page SHALL call GET /api/hold-history/department separately

2.0 KiB Raw Blame History