Files
DarkflameServer/dMasterServer/LiveUpdateCoordinator.h
Aaron Kimbrell 109a936798 feat: live updates move every server onto a new build without a restart
With new binaries in place, master moves everything onto them while the
server keeps running (the dashboard's Live update, /liveupdate or SIGUSR2 to
master):

- database migrations of the new build first; a failure stops there
- UGC finishes the jobs it is running (queued rows stay pending), auth
  restarts, chat hands its teams to master for the next chat server; master
  starts the new processes and retries ones that don't come back
- once the new chat server is up (CHAT_SERVER_READY) every world connects at
  once and sends its players again (LoginSessionNotify resync, no login logged)
- every world instance is replaced with an instance migration: public worlds
  and private ones (same password) at once, properties after the old instance
  saved and froze the property (MIGRATE_PREPARE: no building, claiming or
  saving there any more), activity zones and character select once their
  players left or after a wait; empty instances just stop, zones in
  prestart_worlds get a new one first
- the dashboard restarts last and picks the status up again

Players land where they stood (position carried in CarriedPlayerState, also on
properties and Moon Base). Draining instances get no new players
(InstanceMigration::AcceptsNewPlayers) and show as "Moving players" in the
world list. The order lives in LiveUpdateMachine.h without master state and is
unit tested; master's glue is LiveUpdateCoordinator. Master itself is not
replaced. Message IDs are appended only.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-28 22:31:23 -05:00

49 lines
1.7 KiB
C++

#ifndef __LIVEUPDATECOORDINATOR__H__
#define __LIVEUPDATECOORDINATOR__H__
#include <functional>
#include <string>
#include "LiveUpdateMachine.h"
#include "master/LiveUpdate.h"
/**
* Master's side of live updates (docs/LiveUpdate.md): runs LiveUpdate::Machine against the instance manager, the
* instance migrations and the other servers. Started from the dashboard (LIVE_UPDATE_REQUEST), a GM's /liveupdate or
* SIGUSR2 to master. Main thread only.
*/
namespace LiveUpdateCoordinator {
// What MasterServer.cpp provides: the other servers, and where statuses go
struct Hooks {
std::function<LiveUpdate::ServiceView(LiveUpdate::eService)> service;
std::function<void(LiveUpdate::eService)> retire; // LIVE_UPDATE_RETIRE (chat, UGC) or SHUTDOWN (auth, dashboard)
std::function<void(LiveUpdate::eService)> stop; // SHUTDOWN
std::function<void(LiveUpdate::eService)> start; // start its process
std::function<void()> chatReady; // CHAT_SERVER_READY to every world
std::function<void(const LiveUpdateStatus&, bool toWorlds)> publish;
};
void Initialize(Hooks hooks);
// Start one; false (and why) when it can't
bool Start(const std::string& by, LWOOBJID requesterId, int32_t warnSeconds, std::string& error);
// LIVE_UPDATE_REQUEST (the sender is checked by master: the dashboard, or a world for a GM)
void HandleRequest(const LiveUpdateRequest& request);
// Every instance migration's progress (MigrationCoordinator's observer)
void OnMigrationStatus(const MigrationStatus& status);
// Every master frame
void Update();
// Master is shutting down
void Abort(const std::string& why);
bool IsRunning();
LiveUpdateStatus Status();
}
#endif //!__LIVEUPDATECOORDINATOR__H__