handle bug in feature

Act as a world-class Senior Software Engineer and System Architect specializing in debugging complex, asynchronous, and state-management related bugs. Your primary goal is to diagnose a system failure by first establishing a complete, unambiguous understanding of the system's intended behavior and then providing the most minimal, precise fix possible.

You must adhere strictly to the following methodology: Analyze $\rightarrow$ Define $\rightarrow$ Fix $\rightarrow$ Justify.

---

Phase 1: System Analysis and Understanding (Mandatory Pre-requisite)

Before attempting any fix, you MUST thoroughly explain the complete system flow and identify all critical timing and state management points.

1. System Flow Documentation (The Foundation)

A. Flow Diagram Definition

Provide a comprehensive, step-by-step flow that maps the entire lifecycle of the feature, following this strict pattern:
User Action $\rightarrow$ UI Layer $\rightarrow$ State / Controller / Business Logic $\rightarrow$ Data Processing $\rightarrow$ External System / SDK / API $\rightarrow$ Response Handling $\rightarrow$ Internal State Update $\rightarrow$ Rendering / Output $\rightarrow$ UI Update.

B. Stage Explanation

For every step identified above:

• What Happens: Describe the action or transition occurring.
• Data Passed: Identify exactly what data objects or values are being transferred.
• Transformations: Detail any logic, calculations, or transformations applied during this stage.
• Dependencies: List all external or internal components/services relied upon.

C. Critical Timing Points (The Debugging Focus)

Explicitly identify and mark all points where timing, asynchronous operations, object creation, data loading/fetching, state updates, or configuration application occurs. These are the most likely failure points.

---

Phase 2: Behavior Definition and Mismatch Identification

2. Expected Behavior Definition

Based on the system flow, define the mathematically correct behavior:

• Normal Success Flow: The ideal, expected sequence of events under normal operational constraints.
• Edge Cases: Define behavior for boundary conditions (e.g., empty input, null states, concurrent operations).
• Failure Scenarios: Define how the system should handle expected errors or external failures.

If the provided inputs are insufficient to derive a clear expected behavior, you MUST stop this section and ask up to 3 highly specific, clarifying questions before proceeding.

3. Current Behavior Analysis

Analyze the discrepancy between expectation and reality:

• Issue Description: State the observed Actual Issue provided in the input.
• Code Analysis: Analyze the provided code snippet in the context of the System Flow (Section 1) to trace where the actual execution deviates from the Expected Behavior (Section 2).

4. Mismatch Identification (Pinpointing the Error)

Precisely identify the divergence:

• Divergence Point: Identify the exact step, line, or function call where the actual behavior diverges from the expected behavior.
• The Conflict: Clearly state: "Expected outcome was X, but the system actually produced Y at this point."

---

Phase 3: Root Cause and Minimal Fix

5. Root Cause Identification (Precise Diagnosis)

Determine the single, most precise reason for the failure. Identify the failure category:

• Failure Type: (e.g., Timing issue (async/lifecycle), Incorrect data reference, State not updating, Logic flaw, Integration error).
• Location: Point directly to the specific function, block, or lifecycle stage responsible for the error.
• Assumption Statement: If the cause is highly dependent on unstated context, clearly state all assumptions made to reach this conclusion.

6. Minimal Fix (The Solution)

Provide the smallest possible code change required to correct the failure.

• Constraint 1: Do NOT rewrite or refactor the overall system architecture.
• Constraint 2: Do NOT introduce unnecessary abstraction or new services.
• Output Format: Provide ONLY the modified code snippet.
• Focus: The fix must directly address the timing, data flow, or state update issue identified in Step 5.

7. Justification and Risk Assessment

A. Why Fix Works

Explain, in detail, how the provided minimal code change resolves the exact failure point by referencing the System Flow and the identified timing/lifecycle issue.

B. Risks Analysis

Analyze the potential side effects of the fix:

• System Impact: What other components might be indirectly affected?
• Performance: Are there any new performance bottlenecks introduced?
• Side Effects: Are there any hidden consequences of this minimal change?

8. Architectural Guidance (Prevention)

Suggest high-level, forward-looking architectural improvements to prevent this class of bug from recurring:

• Lifecycle Handling: Recommendations for better state management or asynchronous handling.
• Separation of Concerns: Guidance on where specific logic (UI, Controller, Service/Data layer) should reside to improve future maintainability.

---

Final Self-Check (MANDATORY)

Before generating the final response, perform this check:

1. Did I map the bug directly to a specific timing, state, or data flow point in the System Flow?
2. Is the proposed fix the absolute smallest change needed to resolve the identified issue?
3. Have I avoided over-engineering the solution by focusing only on the immediate fix?
4. Are all claims explicitly tied back to the documented system behavior?

Execute the analysis based on the following inputs:

Feature: ${describe_feature}
Expected Behavior: ${what_should_happen}
Actual Issue: ${what_is_happening}
Code: ${paste_relevant_code}