Implement Search and Filters, Then Diagnose a Query-Ordering Bug

Build search and filtering for an existing web application using a React client and a Python FastAPI backend. Start by eliciting the missing requirements, then explain an implementation and how you would diagnose a related filtering defect in a metrics code path. The debugging observation is limited: moving the query's filtering step later in the code makes filtering take effect. The original implementation and data schema are unavailable, so do not assume a particular faulty line or ORM. ### Constraints & Assumptions - Search and filters must affect the items displayed in the web application. - React and FastAPI are the chosen stack for this practice exercise; the problem does not require a particular database. - Practice clarification: to make examples concrete, treat an item as having an ID, a searchable name, and a filterable status. These illustrative fields are not reported assessment requirements. - Exact search matching, filter combinations, pagination, and metrics definitions remain requirements to resolve. State a consistent choice before using one in your design. ### Clarifying Questions to Ask - Is name search exact, prefix, or substring matching, and is it case-sensitive? - Do multiple selected statuses mean any selected status, and how do status filters combine with the search term? - Should metrics summarize all matching items or only the currently displayed page? - When input changes quickly, should the UI search on every change, after a short idle period, or only after submission? ### Part 1 — Define and Implement Search and Filtering Describe the requirements conversation, the request/response contract, the backend query flow, and the React state flow. Explain how the page should behave for empty results, invalid filters, loading, errors, and responses arriving out of order. #### What This Part Should Cover - A precise matching rule and filter-combination rule that both client and server implement. - One server-side filtered relation shared by result retrieval and any matching-item count. - Controlled React inputs and protection against obsolete responses replacing newer results. - Tests that distinguish searching alone, filtering alone, and their combination. ### Part 2 — Diagnose the Metrics Filtering Defect Investigate why moving filter construction later could repair a metrics-related path. Identify plausible ordering mistakes, explain how you would distinguish them from evidence, and give the correct order of operations for your chosen metrics meaning. #### What This Part Should Cover - Where the base query is created or replaced, when filter values become available, and when the query executes. - The difference between moving a filter after base-query construction and moving it after materialization or pagination. - A regression example in which unfiltered, page-only, and correctly filtered metrics differ. ```hint Trace the lifetime of the query Follow the query object and filter values from request parsing through metrics calculation. Check whether a later assignment discards an earlier filter. ``` ### What a Strong Answer Covers The same search/filter contract should govern the UI, returned items, and metrics. The proposed repair should explain the observed ordering dependency while preserving uncertainty about the unavailable original code. ### Follow-up Questions - How would you keep a count badge consistent with the visible results while a newer search request is pending? - How would you verify that a filter applied to the metrics path was not silently lost when a new base query was assigned?