---
title: "One Line of Config Left Over From a 2023 Branch"
canonical: https://dxdev.com/blog/the-three-year-old-debug-flag/
datePublished: 2026-04-28
---
On April 28, 2026, we fixed a one-line setting that had been wrong since 2023: `EDIT_DATABASE` was still `false`.

The symptom was blunt. Comments on an admin details page would not save. The ticket that came in described exactly that. No intermittent error, no strange edge case. Just a form that accepted input and failed to persist it.

The fix itself was not interesting:

```text
EDIT_DATABASE=true
```

What made it worth writing down was where that line came from. The work had resumed on an old branch. Three years earlier, while we were working an earlier ticket, someone had flipped `EDIT_DATABASE` for debugging. That was a sensible local move. The mistake was not restoring the switch when that earlier work was done. The branch sat with its debugging state intact, then later became the starting point for a production change.

We shipped the details-page fix on April 24. Four days later, the comments were still not saving because the old guard was still active. It sat in a piece of scaffolding that had survived long enough to look normal.

## The diagnostic path was shorter than the history

The first observation pointed us at the write path. The page received the comment, but the database did not get it. That narrowed the problem from the page as a whole to the condition that permits an edit.

The relevant endpoint was a details handler in the legacy application. It looked like a bad save routine at first, because the visible failure was a missing record. But the handler had been configured not to edit the database.

```text
EDIT_DATABASE=false
```

That line explained the whole failure. There was no database migration to repair. No malformed payload. No concurrency problem. No permission change. The application was following the configuration it had been given.

The branch history then changed the question from "why does this page not save?" to "why did a [debugging control from 2023](/blog/edit-database-false-debug-flag-shipped-after-years/) reach a 2026 release?" The answer was mundane and more dangerous than a novel bug: we resumed old work without rechecking the surrounding scaffolding.

The failing symptom made several explanations look plausible. A second ticket, about an upgrade dialog on a different admin page, had also stopped doing anything, and we had noted it as possibly related. So the plan for the session was to check whether both came from one shared regression.

The first thing we read was the change that had just landed on the details handler, which had switched a try/catch back on. It looked like a strong candidate. Then we saw it could only hide an error, not cause a missing save. So we opened the page, saved a test comment and read the response. The server said the comment had been updated, and the SQL was printed as text in the body instead of being run.

There was no error to hide, so we left the other dialog out of this fix. Tracing the form request or the schema any deeper would only have proven that a disabled write path did not write. Patching the new code would have wrapped a second layer of behavior around a switch that was supposed to have been restored.

The correct repair was to restore the intended production setting. That is the entire code change. The larger change is procedural.

## An old branch is not neutral ground

We added a [resumed-branch scaffolding audit](/blog/diff-stale-branch-for-scaffolding-before-merge/) to our learnings after this incident. It is a targeted search for conditions that were useful when the branch was active and unsafe once the branch is back in production work.

For a branch like this, the audit starts at the edges of normal execution: edit guards, feature flags, development-only constants, temporary error handling, stubbed integrations, and conditions that suppress writes. We compare those controls with the current ticket before we assume the branch is a safe base.

The sequence matters. We do this before treating the existing branch behavior as a baseline. If we start from the assumption that all surrounding code is intentional, a three-year-old debug choice becomes invisible. It gains legitimacy just because it is already there.

We could require a fresh branch for every change and abandon old branches entirely. That would prevent this particular carry-over, but it would also discard useful in-progress work and does not protect against old debug state in long-lived shared code. We do review, but review is usually focused on the diff. The flag that caused the damage was not new. It was exactly the kind of unchanged context a diff does not force anyone to revisit.

A resumed branch contains historical intent until proven otherwise. It may still hold valuable work. It may also hold a debug switch from 2023 that silently turns off a production write in 2026.

This one cost us four days between ship and repair. When work resumes on an old branch, check for leftover debugging switches, edit guards and conditions that suppress writes before treating the branch as a baseline. The audit starts with the scaffolding, then the feature.