Exit() was never wired, so it was dead code either way. Wiring it correctly
depends on which teardown path is running.
On a normal shutdown EventSink.Shutdown fires on the game thread after the
loop has stopped, which is the last chance pending work gets: results the
worker already posted are sitting on a loop context nothing will pump again.
So the thread is stopped, the context drained once, and queued writes are
computed and applied in place. Verifies are dropped instead -- they only
decide a login, and every connection is closing.
On a crash there is no usable game thread, so nothing may be applied and the
thread is simply stopped. Subscribed separately because HandleClosed skips
InvokeShutdown when _crashed is set, which would otherwise leave the crash
path unhandled entirely.
Wired from AccountHandler.Initialize rather than a Configure on the worker:
AssemblyHandler.AddMethods binds Static | Public, so a Configure on an
internal type is never discovered.
SetPassword derives a full Argon2 hash, so the [password command, the admin
gump, account creation and the XML import each cost ~8.9 ms of frozen world.
Only the login verify had been moved.
DRY-ing the two paths surfaced a correctness trap rather than just shared
code. ApplyPasswordUpgrade guarded by comparing the stored hash, which is
right for a login rehash -- do not clobber a newer password with a rehash of
the one it superseded -- but wrong for an explicit change: two changes
dispatched before either landed would drop the second and silently keep the
older password. Ordering is now a per-account dispatch sequence claimed on
the loop, which gives "newest wins" for both callers through one mechanism.
SetPassword bumps it as well, so an inline write also supersedes an in-flight
one.
One job type serves both: PasswordJob carries an optional verify phrase and
an optional hash phrase plus an OnComplete that runs on the loop, so a login
verifies and may rehash while a password change only hashes. The class is
PasswordWorker now, since verification no longer describes what it does.
PasswordWorker.SetPassword is the single entry point and falls back to
hashing inline when the gate is off or the queue is saturated -- unlike a
login, a password change must never be silently dropped, and it is rare
enough that the loop can absorb one.
The [password confirmation moves into the callback, because off the loop it
has not happened when the call returns. Account creation stays inline: it
gates the login flow, so deferring it restructures the accept path.
2026-08-08 12:25:49 -07:00
Renamed from Projects/UOContent/Accounting/Security/PasswordVerificationWorker.cs (Browse further)
