Repository navigation
Configure the Bot Social server in Settings - #341
Conversation
Settings → Bot Social shows the server, where it comes from and the connection, and switches to another server live. The address is validated (https, http only for localhost) and checked against /v1/platform before anything is saved; a switch needs a confirm that says a new server is a new identity. Each server has its own credentials, settings and per-Bot identities; the old credentials file is kept, never deleted, and switching back restores it. A failed switch puts the previous server back. cordis.patch.yml stays the default. Plugins add Settings pages through the new flybot.settings.page slot.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 865e9a876c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| current = previous | ||
| lastProbe = undefined | ||
| // launch() has already recorded the failure (state, error, the unavailable answers); the message below reports it. | ||
| await launch(previous).catch(() => undefined) |
There was a problem hiding this comment.
When a new server gets through createSocial() but hangs in registerAll() for longer than 45 seconds, that pending start already owns the social API handlers and middleware, while the controller cannot dispose it until the promise settles. Relaunching the previous server here therefore collides with those registrations and fails, leaving Social unavailable until restart instead of restoring the previous server. The timed-out start must be cancelled or allowed to settle and dispose before relaunching.
Useful? React with 👍 / 👎.
| if (!server) return { ...base } | ||
| const key = serverKey(server) | ||
| const name = displayName ?? base.displayName | ||
| if (key === defaultKey) return { ...base, server, ...(name ? { displayName: name } : {}) } |
There was a problem hiding this comment.
If the profile's config.server is changed to a server that was previously selected in Settings, this branch starts using the base credentials path even though that server's credentials are stored in the tagged path. The base file still belongs to the old default, so startSocial() treats it as a mismatch and onboards a second identity; existing friends disappear, and restored member IDs may be invalid under the new token. Select or migrate the existing credentials that match the server before assigning the default path.
Useful? React with 👍 / 👎.
| const info = await probe(address, { fetch: base.fetch }) | ||
| const previous = current | ||
| const target = { server: address, displayName: name, source: serverKey(address) === defaultKey ? 'config' : 'settings' } | ||
| stop() |
There was a problem hiding this comment.
On a server switch, stop() disposes the old social instance but does not clear the core's published remote-Bot list. The new startSocial() refreshes that list asynchronously and suppresses refresh failures, so the switch can return while friends from the old server remain visible—and they remain indefinitely if list_remote_bots keeps failing—even though subsequent actions use the new server's transport. Clear the social remote roster as part of the identity switch before exposing the new connection.
Useful? React with 👍 / 👎.
Fixes #337
Settings → Bot Social shows the Bot Social server FlyBot uses and its connection, and switches to another server without editing
cordis.patch.ymlor restarting.Connected as @handle, connecting, error, no server), and the features<server>/v1/platformlists. Change server → address → Check → warning → Switch to this server. zh strings are ini18n.js. It is a plugin page: new slotflybot.settings.page(after Connectors; gets the hostt,Section,Row), so the page exists only when the social plugin does.https://(http://only for localhost / 127.0.0.1 / [::1]); no user name, query or fragment. The host probes/v1/platform(no credentials, 8 s, redirects refused) before saving;server-setrepeats the checks, so skipping Check gains nothing.flybot-social.json.<tag>, the suffixstartSocialalready used for backups), settings file, and parked per-Bot identities/grants/Auto-send marks (flybot-social-bots.<tag>.json, no token), so a stale grant to@bob.homecannot apply to a different Bob on the new server. Switching back restores them with no second onboarding.flybot-social-server.json(0600) beside the credentials;config.serverstays the default/fallback. Nothing configured: behaviour unchanged (same start failure as before; the page says "No server set").social/servercarries none; tests assert it).social/server-check/social/server-setare writes for the access rules (no read-only host, no team of several members).Not in scope: Bot Social itself; face-to-face rooms already hosted from the old server stay as local transcripts (nothing polls them).
Tier. T3 (
plugins/social/index.js,src/**,cordis.patch.yml): needs an independent PASS and the maintainer; not enabling auto-merge.Ran at the tip:
ARCH_DOCS_BASE=origin/main TZ=UTC npm run verifygreen (core 869, social 230, tree 56, timeline 80, github scripts 86, interop 37, live-e2e 16). New tests: server address validation, probe, switch/restore/rollback/timeout/read-only (plugin), the Settings page states and zh coverage (plugin), theflybot.settings.pageslot in the Settings dialog (core).Not run: a real browser (the page was rendered with real React to static HTML and driven through scripted states, not clicked); the smoke bench (
dev/bench.sh, no deepseek-harness checkout here); a real Bot Social server (a mocked fleet was used).