Documentation
¶
Overview ¶
Package settingsresolve lets a data directory's already-persisted node settings supply the effective value for any override-eligible gate an operator left at its built-in default, before the rest of configuration resolution runs. This is the mechanism behind "dingo -n preprod", a stop, then a bare "dingo" resuming preprod instead of failing to sync from scratch -- while "dingo -n preview" against that same database is still a fatal error naming the conflict, because an operator-supplied value is never silently discarded.
Apply opens only the metadata store -- read-only in effect, since it persists nothing itself; the real database.New does that -- and only long enough to read the legacy node_settings row and the node_settings_gate table. It never touches the blob store: badger's exclusive directory lock would block the real open moments later, and merely opening it would mint a blob_store_id as a side effect of reading configuration.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func Apply ¶
Apply reads cfg.DatabasePath's persisted node settings and, for every override-eligible gate (database/nodesettings.Gates) the operator did not set explicitly, replaces cfg's built-in default with the persisted value. An operator-supplied value that conflicts with what the database already is returns an error naming the gate, both values, and which configuration source supplied the value -- it never gets silently overridden.
Apply is a no-op, returning nil, whenever there is nothing safe or useful to resolve: a database directory that doesn't exist yet (a first run), one that exists but is empty (a pre-created volume mount, or a `dingo database restore` target), or one this process could not open for any reason. A corrupt or in-use database is database.New's problem to report properly; failing here would only mask its better error behind a worse one.
On every nil-returning path -- including the no-op ones above, where cfg is left completely unchanged -- Apply publishes cfg via config.PublishConfig before returning. This matters even when nothing was overridden: LoadConfig and ApplyFlags already publish their own results to the same process-wide snapshot, and cmd/dingo's later LoadTopologyConfig call reads that snapshot via config.GetConfig rather than the *Config pointer being threaded through main.go's PersistentPreRunE. Without Apply publishing too, an override it made (e.g. resuming Network from a persisted gate) would be visible on cfg itself but invisible to GetConfig, so topology would resolve against the stale pre-override network while every other consumer of cfg used the resumed one -- a real, previously-shipped bug (a bare resume dialed the wrong network's relays while handshaking with the resumed network's magic) that Apply changing cfg without republishing caused.
Types ¶
This section is empty.
Source Files