The Blazor Closure Bug That Made All My Time Slots 24:00 🕛 🕛

🐛 The Mysterious Bug

I was building a conference room booking system in Blazor when I encountered a bizarre bug. My timeline component showed time slots from 6 AM to 11 PM, but whenever I clicked any time slot, it would always show 24:00 in the console.

// Console output - ALWAYS showed 24!
Time slot selected: 24:0
Start: 06-01-2026 00:00:00, End: 06-01-2026 01:00:00

The timeline looked correct visually, but every single button was broken. How could all buttons from 6 AM to 11 PM send "24" as the hour?

🔍 The Investigation Journey

My first assumptions were all wrong:

1. Timezone issue? - Checked DateTime.Kind, UTC conversions
2. DateTime parsing bug? - Added extensive validation
3. Browser datetime-local bug? - Tested across browsers

After 3 hours of debugging, I added more logging:

private async Task OnTimeSlotClick(int hour, int minute)
{
    Console.WriteLine($"[DEBUG] Clicked hour: {hour}");
    // Always showed 24, regardless of which button!
}

The maddening part? The loop looked perfectly correct:

<!-- This SHOULD create buttons for hours 6-23 -->
@for (int hour = 6; hour < 24; hour++)
{
    <button @onclick="() => OnTimeSlotClick(hour, 0)">
        @hour:00 <!-- Shows 6:00, 7:00, 8:00... CORRECT! -->
    </button>
}

Buttons displayed: 6:00, 7:00, 8:00... but all called OnTimeSlotClick(24, 0) when clicked!

💡 The Revelation: Closure Capture

The issue was closure capture - a classic C# gotcha that's especially tricky in Blazor!

// What's ACTUALLY happening:
for (int hour = 6; hour < 24; hour++)
{
    // ❌ Captures the VARIABLE 'hour', not its VALUE!
    button.Click += () => OnTimeSlotClick(hour, 0);
}

// When loop finishes: hour = 24
// ALL click handlers now reference hour = 24!

In C#, lambdas capture variables, not values. By the time any button is clicked, the loop has completed, and hour = 24 (the loop exits when hour < 24 is false).

🛠️ The Simple Fix That Worked

I changed from for to foreach with Enumerable.Range:

<!-- ✅ THIS WORKS! -->
@foreach (var hour in Enumerable.Range(6, 18)) <!-- 6 to 23 -->
{
    <button @onclick="() => OnTimeSlotClick(hour, 0)">
        @hour:00
    </button>
}

Why this works: Each iteration of foreach creates a new variable in memory, while for reuses the same variable.

🔧 Alternative Solutions

1. Local Copy in Loop (Most Common Fix)

@for (int hour = 6; hour < 24; hour++)
{
    var currentHour = hour; // ✅ Local copy
    <button @onclick="() => OnTimeSlotClick(currentHour, 0)">
        @currentHour:00
    </button>
}

2. Method with Parameter

@for (int hour = 6; hour < 24; hour++)
{
    <button @onclick="@(() => HandleHourClick(hour))">
        @hour:00
    </button>
}

@code {
    private void HandleHourClick(int hour) // ✅ New parameter each call
    {
        OnTimeSlotClick(hour, 0);
    }
}

3. Use @key to Force Re-renders

@for (int hour = 6; hour < 24; hour++)
{
    <div @key="hour"> <!-- ✅ Forces new component instance -->
        <button @onclick="() => OnTimeSlotClick(hour, 0)">
            @hour:00
        </button>
    </div>
}

🎯 Why This Happens in Blazor Specifically

Blazor makes this bug more likely because:

1. Event handlers are lambdas that execute later
2. Component lifecycle delays execution until after render
3. State changes trigger re-renders, changing captured variables
4. Async nature means lambdas execute long after loop completes

📚 The Universal Lesson

This isn't just a Blazor problem - it's a closure capture issue that appears in:

• JavaScript: Same issue with var in loops
• C#: Any lambda in a loop
• Java: Anonymous classes capturing loop variables
• Python: Similar issues with default arguments

The rule: When creating lambdas/events in loops, ensure you're capturing values, not variables.

🤔 Debugging Tips for Similar Issues

1. Add immediate logging in the lambda
2. Test with hardcoded values to isolate the issue
3. Check if it's a closure problem by creating local copies
4. Remember: Loops with lambdas are always suspicious!

💭 Final Thoughts

This bug taught me that sometimes the simplest-looking code can have the most surprising behavior. What looks like a primitive int in a loop actually becomes a shared reference across all event handlers.

Have you encountered similar closure bugs? What's your favorite "it can't be that" debugging moment?

---

Discussion:

• Have you been bitten by closure capture bugs?
• What other Blazor gotchas have you encountered?
• Share your favorite debugging stories!