ENG-1408 - Suppress env errors if SUPABASE_USE_DB="none"

[mdroidian]

These error messages appear on every plugin load/reload, which is poor DX—especially when the configuration explicitly indicates that the database is not in use (SUPABASE_USE_DB="none").

https://github.com/DiscourseGraphs/discourse-graph/blob/main/packages/database/README.md#L11-L12

## Developing without the database

Your frontend will not use the database.
Optional: Set `SUPABASE_USE_DB=none` in your console before running `turbo dev`. (This is now the default.)

This PR introduces a small, targeted fix and establishes a clear pattern we can reuse for handling future database-specific functionality.

---

[linear]

ENG-1408 Suppress env errors if SUPABASE_USE_DB="none"

[mdroidian]

@maparent will define: "process.env.SUPABASE_USE_DB": dbEnv.SUPABASE_USE_DB conflict with createEnv.mts?

[maparent]

Ok, sorry it took me so long to get to this. I'll be honest: The error is verbose, and I'm not against trying to make it a bit less so, but I think it's a real error and I'm -1 on silencing it in the first place. You have set suggestion mode on, it cannot work because you disabled that database, it's an error condition you should be warned of.
Second, SUPABASE_USE_DB was meant to be a build-time variable, not a runtime variable. I don't think the runtime should know about this. Imho all it needs to know is that it did not get the variables it wants, complain once, and call it a day. I created FatalError so it would fire only once ; what we should do is avoid having two error traces.
For that I suggest inverting lines 88 and 89 of supabaseContext.ts or even deleting 88.

[mdroidian]

Ok, sorry it took me so long to get to this. I'll be honest: The error is verbose, and I'm not against trying to make it a bit less so, but I think it's a real error and I'm -1 on silencing it in the first place. You have set suggestion mode on, it cannot work because you disabled that database, it's an error condition you should be warned of. Second, SUPABASE_USE_DB was meant to be a build-time variable, not a runtime variable. I don't think the runtime should know about this. Imho all it needs to know is that it did not get the variables it wants, complain once, and call it a day. I created FatalError so it would fire only once ; what we should do is avoid having two error traces.For that I suggest inverting lines 88 and 89 of supabaseContext.ts or even deleting 88.

That is not sufficient from a DX standpoint.

I reload the plugin dozens of times a day. When the database is intentionally disabled, receiving an error on every reload is unnecessary noise.

You said: “You have Suggestive mode on. It cannot work because you disabled the database. It’s an error condition you should be warned of.”

That is not accurate in this context. I am explicitly stating that I do not want to use database-backed features. If I set SUPABASE_USE_DB="none", that is an intentional opt-out. In that case, it is not an error condition — it is expected behavior. There is nothing to warn about.

The overwhelming majority of our functions are local-only. Requiring a developer to manually toggle all database-related settings inside the graph introduces unnecessary time overhead and friction. A single variable to disable DB behavior is a clean and efficient development switch.

You also stated that the runtime should not know about this, but the core question remains unanswered:

• What are the concrete downsides of the runtime being aware of SUPABASE_USE_DB="none"?
• Is there a real technical or architectural risk?
• If the build-time flag resolves to a constant, isn’t the runtime effectively branching on a static value anyway?

If there is a concrete downside, please explain it clearly. If there is not, please go ahead and review this PR.

[maparent]

Ok. I won't fight this further. Do as you wish. Send the variable. I will ask for one modification: In that case, have a console.warn("The database was expected disabled through developer-mode settings") or some such, so people know what's happening if they forget what setting they set and they expect the database to work.

[maparent]

I'll review tomorrow, done for the day.

[maparent]

This is only one of many places that call getLoggedInClient.
Instead of doing this at call points, I suggest doing this globally in the getLoggedInClient function. It would require passing the USE_SUBAPABASE_DB variable in obsidian build.
If you want to do it at call points, look for getLoggedInClient globally.
In all cases, the error should be converted in a warning. A developer who got the wrong settings in their build console should get a signal to understand why they are not getting database access.