wtclaude
6a276a7ec3
The website half of the protocol-5 bump. Engagement Phase 10.
Schema — twelve columns and two indexes.
shard_houses gains next_stage, estimated_collapse, decay_period_sec and
dynamic_decay. estimated_collapse is nullable and stays null far more often than
not, deliberately: under dynamic decay ServUO draws each stage at random on entry,
so collapse is knowable only at IDOC. A null means "not knowable", never "not yet
read".
shard_vendors gains owner_acct plus seven fee columns and an index on dismissal_at.
owner_acct is the structural one — the table has carried owner_name since protocol
3, but a character name joins to nothing, and only the game account reaches
shard_account_links. Until now a vendor row named an owner the site could not
resolve to a person. dismissal_at + owner_acct are what let Phase 11's
uo.vendor.expiring find "vendors about to be dismissed" and turn each into a
person, without scanning every shop.
Ingest.
Both new field groups arrive NESTED and are flattened into columns on the way in,
then re-nested on the way out — the same trick shardMarket already uses for
`location`. That is not stylistic: the visibility projection matches literal JSON
keys, so the stored read model and the live wire frame have to spell a group
identically or one admin rule covers only one of the two paths. It also means a
field added inside a group later inherits the group's gate instead of defaulting to
visible; there is a test that adds an imaginary future fee field and asserts exactly
that.
Two write-back asymmetries, both load-bearing:
* ownerName is written ONLY when the frame carries one. house.update also writes
that column, from a different sweep, and a pre-v5 overlay's house.decay carries
no ownerName at all — coalescing to null would let every decay transition erase
a name the registry had already resolved.
* The schedule and fee columns are written UNCONDITIONALLY, including as nulls. A
schedule is a claim about the future and goes stale on its own: roll a shard
back to a pre-v5 overlay, or let a house leave IDOC, and the right stored value
is nothing. A dismissal date nobody is maintaining is worse than none.
dismissalAt is taken from the shard rather than recomputed. The shard resolved it
against ServUO's two vendor systems, whose charge, funds and pay interval all
differ; re-deriving it here would be a second implementation of PlayerVendor's own
rule.
Visibility — three classifications, each chosen rather than inherited.
* house.decay's `schedule` defaults to `anonymous`. The countdown IS the public
IDOC page's content and a house at IDOC is already announced in game. Listed
anyway so a shard that considers a precise collapse time an unfair advantage can
raise it — and one nested rule takes the whole schedule with it.
* vendor.listing's `fees` defaults to `admin`, the only default in the market
feature that does not reproduce prior behaviour, because there is no prior
behaviour to reproduce. Shop name, owner and location are already visible to any
player through the in-game Vendor Search gump, which is the argument for
publishing them. Held gold, daily charge and dismissal date are visible to the
OWNER only, on that vendor's own gump. Publishing them anonymously would be a
new disclosure and a targeting aid — which shops are about to be abandoned, and
how much coin is in each.
* account.login.result is admin-only BY OMISSION. KIND_FEATURE is the map of kinds
an admin may widen, and there is no rung below admin that an IP plus an auth
verdict belongs on. The omission is the decision, and a test says so by name.
owner_acct needs no rule: rule 1 locks it by suffix. And the new columns are in no
REST read model's column list — they exist for Phase 11's server-side trigger and
reach no client at all.
The pin, and the protocol-4 bug seen from the other side.
Both declaration sites go to 5 (the model constant and schema.sql's CREATE default),
plus the one-shot migration, guarded `protocol < 5` so an install that missed an
earlier step is carried the whole way.
The schema test used to assert `DEFAULT 4` at each site. That is exactly how
protocol 4 shipped with the emitters moved and one site left behind: every site
agreed with itself and the test passed. It now reads DEFAULT_PROTOCOL from the
model, so the assertion is "the declarations AGREE", and the one-shot migration
test is written once against the current version instead of being hand-copied per
bump.
470 tests pass, 16 new. Verified end to end on the live rig against a real ServUO
and the release sidecar.
Docs: RunicGateway/docs link/v5.md.
Co-Authored-By: Claude <noreply@anthropic.com>
102 lines
4.5 KiB
JavaScript
102 lines
4.5 KiB
JavaScript
// uo-link sidecar connection config store. Mirrors botConfig/emailConfig: the DB
|
|
// layer only ever sees ciphertext, and only getWithToken() (used server-side to
|
|
// call the sidecar over REST/WS) decrypts it. The admin-facing getSafe() never
|
|
// includes the token — it exposes only `hasToken`. A blank `token` on save means
|
|
// "leave the existing token unchanged" (same convention as the other configs).
|
|
|
|
const db = require('./uoLinkConfig.db')
|
|
const { secretBox } = require('../../core')
|
|
|
|
// The wire protocol this build speaks (link/sidecar/src/main.rs PROTOCOL_VERSION).
|
|
// Only used before an admin has saved anything — the stored row wins once it exists,
|
|
// and UOLINK_PROTOCOL still overrides for an operator running an older sidecar.
|
|
//
|
|
// This says 5 because this build handles protocol 5's frames: house.decay's `schedule`,
|
|
// vendor.listing's `ownerAcct` + `fees`, and the new `account.login.result` kind.
|
|
//
|
|
// It said 4 before that, and 3 for a while after protocol 4 shipped — which is the bug
|
|
// this constant is now the fix for. A FRESH install pinned 3, the sidecar answered
|
|
// `409 protocol version mismatch` to every REST call, and a new deployment read nothing
|
|
// from its shard until an admin edited the number by hand in Admin → Shard. Bumping it
|
|
// in the SAME change as the emitters is the discipline that prevents a repeat; see the
|
|
// matching cutover in db/schema.sql.
|
|
const DEFAULT_PROTOCOL = Number(process.env.UOLINK_PROTOCOL) || 5
|
|
|
|
function toSafe(row) {
|
|
if (!row) {
|
|
return {
|
|
baseUrl: process.env.UOLINK_BASE_URL || null,
|
|
wsUrl: process.env.UOLINK_WS_URL || null,
|
|
protocol: DEFAULT_PROTOCOL,
|
|
enabled: false,
|
|
hasToken: false,
|
|
status: 'disconnected',
|
|
statusDetail: null,
|
|
pluginConnected: false,
|
|
lastEventAt: null,
|
|
bootId: null,
|
|
}
|
|
}
|
|
return {
|
|
baseUrl: row.base_url || null,
|
|
wsUrl: row.ws_url || null,
|
|
protocol: row.protocol || DEFAULT_PROTOCOL,
|
|
enabled: Boolean(row.enabled),
|
|
hasToken: Boolean(row.auth_token_enc),
|
|
status: row.status || 'disconnected',
|
|
statusDetail: row.status_detail || null,
|
|
pluginConnected: Boolean(row.plugin_connected),
|
|
lastEventAt: row.last_event_at || null,
|
|
bootId: row.boot_id || null,
|
|
}
|
|
}
|
|
|
|
async function getSafe() {
|
|
return toSafe(await db.get())
|
|
}
|
|
|
|
// Decrypted token included — server-side only (calling the sidecar's REST/WS
|
|
// API). Returns null when nothing has been saved yet.
|
|
async function getWithToken() {
|
|
const row = await db.get()
|
|
if (!row) return null
|
|
return { ...toSafe(row), token: row.auth_token_enc ? secretBox.decrypt(row.auth_token_enc) : null }
|
|
}
|
|
|
|
// Save admin-supplied config. `token` undefined or '' means "leave the existing
|
|
// token unchanged" (same convention as botConfig.save).
|
|
async function save({ baseUrl, wsUrl, token, protocol, enabled, updatedBy }) {
|
|
const fields = {}
|
|
if (baseUrl !== undefined) fields.base_url = baseUrl
|
|
if (wsUrl !== undefined) fields.ws_url = wsUrl
|
|
if (token) fields.auth_token_enc = secretBox.encrypt(token)
|
|
if (protocol !== undefined) fields.protocol = protocol
|
|
if (enabled !== undefined) fields.enabled = enabled ? 1 : 0
|
|
if (updatedBy !== undefined) fields.updated_by = updatedBy
|
|
const row = await db.upsert(fields)
|
|
return toSafe(row)
|
|
}
|
|
|
|
// Mirror the sidecar's last-reported connection state into the DB so the admin
|
|
// panel has something to show between polls and the public status endpoint can
|
|
// read it without a live round-trip.
|
|
async function recordStatus({ status, statusDetail, pluginConnected, lastEventAt, bootId }) {
|
|
const fields = {}
|
|
if (status !== undefined) fields.status = status
|
|
if (statusDetail !== undefined) fields.status_detail = statusDetail
|
|
if (pluginConnected !== undefined) fields.plugin_connected = pluginConnected ? 1 : 0
|
|
// lastEventAt may arrive as an ISO string (e.g. "2026-07-10T22:08:27Z"); the
|
|
// mariadb DATETIME parser rejects the "T"/"Z", so hand it a real Date (same
|
|
// fix as botConfig.recordStatus's last_connected_at).
|
|
if (lastEventAt !== undefined) fields.last_event_at = lastEventAt ? new Date(lastEventAt) : null
|
|
if (bootId !== undefined) fields.boot_id = bootId
|
|
if (Object.keys(fields).length === 0) return getSafe()
|
|
const row = await db.upsert(fields)
|
|
return toSafe(row)
|
|
}
|
|
|
|
// DEFAULT_PROTOCOL is exported for the schema test, which asserts that this constant
|
|
// and schema.sql's two declarations of the same number AGREE, rather than asserting a
|
|
// hardcoded version at each site -- which is what let them drift apart before.
|
|
module.exports = { getSafe, getWithToken, save, recordStatus, DEFAULT_PROTOCOL }
|