Columbia Games / 29 September 2026

HarnQuest admin: clicking Save is not proof that a checkbox value persisted

We added HQ status management for customers, then fixed a legacy-data persistence bug with database verification and regression coverage.

2 min read
Columbia GamesBackendAdmin
HarnQuestlegacydatabaseregression
Technical illustration of HarnQuest administration, toggle persistence and database verification
A successful update must remain correct after the database state has been read back.

Situation

HarnQuest membership was not convenient to manage in the existing administration interface, so we introduced a toggle. Early testing revealed that for some customers the selected state disappeared after saving and reloading. A successful frontend response did not prove that the expected value had reached the database, and historical customer classes did not always follow today's normalization rules.

Approach

We examined the HQ read and write paths in both API and UI, introduced numeric-safe boolean normalization and verified persisted state by reading it back after updates. Unusual legacy customer-class values were preserved unchanged so unrelated fields could no longer block HQ updates. Regression tests were added for the read–write–reload cycle, and the fix was promoted through a production release.

Outcome

The HQ state now survives reloads while existing legacy customer data remains intact. A successful save indication is tied to verified persistent state rather than merely to a non-error API response.