The production bug that made me care about undefined behavior

A struct declared without an explicit initializer runs its default constructor, but primitive members like bool remain indeterminate. In a payment service the Response struct had bool error and succeeded fields that were never set, so one request returned both flags true, a state that should be impossible. This happened because the presence of a std::string forced the compiler to generate a default constructor that only initialized the string, leaving the booleans with garbage values. The bug surfaced in production when the API returned contradictory error and success values, exposing how undefined behavior can silently corrupt business-critical logic. The fix is straightforward: ensure every field has a known value either by adding a user-defined default constructor that zero-initializes the booleans, by giving them in-class default values, or by zero-initializing the object with {} at the call site. Those changes guarantee that the struct starts in a well-defined state and that later assignments behave predictably. For technical leaders the story is a reminder to enforce disciplined initialization patterns, run static analysis tools like clang-tidy, and include sanitizers in the CI pipeline. Treating initialization as a first-class concern reduces hidden technical debt, improves code quality, and prevents rare but catastrophic bugs from reaching customers.