Debug Event Search, Pagination, and Redis Invalidation

A ticketing application uses Django for event search and pagination and Redis to cache event responses. Users report three defects: search filters do not affect results, some pagination inputs cause an exception, and event responses remain stale after an event is created or edited. Explain how you would locate and repair each defect, then verify the fixes together. You are given the following findings from the affected code paths. Treat them as the starting point for diagnosis; the exercise does not require access to an existing repository. ### Part 1 — Search Filters Do Not Change the Results The search handler reads query parameters and constructs filter conditions, but those conditions are not chained into the QuerySet eventually returned by the handler. Describe the correction and explain how you would establish that several supplied search parameters affect the same final query. State how absent or empty parameters should behave. #### What This Part Should Cover - The relationship between each filter operation and the QuerySet that is later evaluated. - Combining multiple supplied filters without discarding earlier conditions. - Verification using records that distinguish a single-filter result from the intended combined result. ### Part 2 — Invalid Pagination Inputs Cause Exceptions The handler accepts `page` and `page_size` from the request. Nonpositive values are not safely handled. Define an explicit policy for missing, malformed, zero, and negative values, and explain where to apply it before pagination arithmetic or database evaluation. #### What This Part Should Cover - Parsing and validation of both parameters, including noninteger text. - A consistent response or fallback policy that does not hide unrelated server exceptions. - Empty results and requests beyond the last available page. ### Part 3 — Event Writes Leave Stale Redis Entries Creating or editing an event changes the database but does not invalidate the Redis responses derived from that event data. Explain what to invalidate, when to invalidate it relative to the database transaction, and how you would verify that both create and update operations reach the invalidation path. Do not assume the cache contains only individual event details; inspect the actual cache keys and their dependencies. #### What This Part Should Cover - Identifying affected detail, search, and paginated responses from the application's actual key scheme. - Preventing a cache invalidation from advertising a write that later rolls back. - The limits of deletion alone when reads and writes occur concurrently. ### Constraints and Clarifying Questions - Preserve the existing event model and the Django/Redis architecture. - Before changing pagination behavior, confirm whether clients expect a validation response or documented defaults for invalid values. - Confirm how cache keys incorporate search filters and pagination parameters, and which write paths bypass the main handler. - No latency target or cache freshness guarantee is supplied. State the guarantee your repair can actually support. ```hint Follow the final response Trace one search request from its parameters through the final database query and cache key. Then trace an event edit through commit and the next request for that same response. ``` ### What a Strong Answer Covers - A repair for each reported defect and how the three paths interact when a filtered, paginated result is cached. - Specific regression cases that would fail under the original behavior. - A clear distinction between the immediate defect fixes and any additional concurrency guarantee that needs a broader cache design. ### Follow-up Questions - If an event changes from matching one search filter to matching another, which cached result sets can become stale? - What happens if Redis deletion fails after the database transaction commits? - How would a concurrent reader repopulate stale data after a deletion, and what change would address that race?