Bdsillok

Why it was hard

0 KRW is a plausible value, so it didn't look like an error. And since the previous year's tax was fixed at 0, the result on screen was the same with or without the bug. It was the kind of bug you can only find by checking the formula line by line with the law beside you.

How I traced it

1. 1. Does the change field actually compare anything?

   It was subtracting the previous year's tax from itself.

2. 2. Where does the previous year's value come from?

   It was fixed at 0, and there was no way to input it at all.

3. 3. Checked against the law, what's missing?

   The tax burden cap in Article 122 of the Local Tax Act wasn't implemented.

4. 4. Do other calculators have the same kind of problem?

   The same method found more P0s in inheritance tax, rental income tax and capital gains tax. In capital gains tax, 8 inputs taken on the screen weren't used in the calculation.

Root cause

The holding tax engine didn't take the previous year's tax as input. It fixed it at 0 and computed the change as 'previous year's tax minus previous year's tax'.

Fix

It now takes the previous year's tax as input and applies a tax burden cap of 105% for a one-home household and 130% otherwise. The change is this year's tax minus the previous year's. In the same audit, I fixed inheritance tax to use Statistics Korea's life expectancy table with linear interpolation, and rental income tax to separate the simple and standard expense rates and compute deemed rent.

previous_year_total = 0
"year_over_year_change": previous_year_total - previous_year_total,

previous_year_total = self._to_int(self.inputs.get("previous_year_tax", 0))
tax_burden_cap_rate = 1.05 if is_one_household_one_home else 1.30
if previous_year_total > 0:
    tax_burden_cap_amount = self.floor_to_won(previous_year_total * tax_burden_cap_rate)
    if total_holding_tax > tax_burden_cap_amount:
        tax_burden_cap_applied = True
        total_holding_tax = tax_burden_cap_amount
"year_over_year_change": total_holding_tax - previous_year_total,

Why it was hard

It didn't reproduce in a freshly opened tab. The error screen hid the cause behind a generic message, and the on-screen 'Try again' couldn't fetch files that were already gone.

How I traced it

1. 1. Is it the API?

   It happened in 4 groups of screens at once. I suspected the browser's file loading before the server.

2. 2. What went missing?

   When the deploy replaced the container, all the lazy-loaded chunk files from the previous build disappeared.

3. 3. How can it recover?

   The only way for an open tab to get the new build was a full reload.

4. 4. How do I confirm it's fixed?

   I used a headless browser to inject chunk 404s into a local production build on purpose. Before the fix, it got stuck on the error screen. After the fix, it reloaded once and then loaded normally.

Root cause

The 4 error boundaries (error.tsx) only logged the error and didn't check whether it was a chunk loading error.

Fix

On a chunk loading error, it reloads once. It keeps the last reload time in session storage and won't reload again within 30 seconds. If storage isn't available, there's no way to prevent a loop, so it doesn't auto-reload at all.

useEffect(() => {
  console.error("Calculator error:", error);
}, [error]);

useEffect(() => {
  if (reloadOnChunkLoadError(error)) return;
  console.error("Calculator error:", error);
}, [error]);

// core of chunk-reload.ts
try { lastReloadAt = Number(sessionStorage.getItem(KEY)) || 0; }
catch { return false; }   // without storage we can't prevent a loop, so don't reload
if (Date.now() - lastReloadAt < 30_000) return false;
sessionStorage.setItem(KEY, String(Date.now()));
window.location.reload();
return true;