gameserver.cpp: AuthenticateServer()/registration-failure paths have no error-detail API to log a real cause
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- cpp
- Domain
- api, authentication, backend, database
Research direction
Start with src/runtime/server/gameserver.cpp, especially OnTcpMsgRegistrationFailure, AuthenticateServer(), and the caller around lines 189 and 1347. Inspect what ServerDB sends in the forwarded msg blob and trace AuthenticateServer() callers before choosing the error-return API. Done means both failure paths expose a real cause in the existing ServerFatal logs without fabricated details.
Written by the indexing model from the issue text.
Description
Found while auditing log message quality in src/runtime/server/gameserver.cpp (repo-wide log audit).
Two ServerFatal(...) call sites have messages that are as good as they can be given what's actually available to them, but what's available is thin:
gameserver.cpp:189(OnTcpMsgRegistrationFailure) —ServerFatal("GameServer registration rejected by ServerDB"). The incomingmsg/msgSizeblob (the actual rejection reason from ServerDB) is forwarded opaquely toBroadcasterReceiveLocalEventand never deserialized in this function, so no rejection reason string is ever available to log.gameserver.cpp:1347(AuthenticateServer()'s caller) —ServerFatal("Server authentication failed — no valid token for ServerDB connection").AuthenticateServer()returns onlystd::string(empty on failure), with no error detail for the caller to surface.
Both messages are honest about what's known — no fabricated data was added to either during the log audit — but an operator debugging a registration/auth failure currently has no cause in the log beyond "it failed."
Fix direction: (1) parse the msg blob in OnTcpMsgRegistrationFailure for a real rejection-reason field (likely a small protobuf/JSON payload — check what ServerDB actually sends on rejection); (2) change AuthenticateServer()'s return type to something like std::expected<std::string, std::string> (or an out-param for the error) so its caller can log a real cause instead of a bare "failed." Both are API changes, which is why they weren't done as part of the log-content-only audit commits.
- Dominant language
- C
- Stars
- 2
- Forks
- 2
- Avg merge
- 3h 8m
- Merged PRs (30d)
- 2
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from EchoTools/nevr-runtime
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
EchoTools/nevr-runtime#30 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
EchoTools/nevr-runtime#27 ·
-
crash-handler plugin: MH_ERROR_ALREADY_INITIALIZED treated as fatal, unlike every sibling pluginOpen
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
EchoTools/nevr-runtime#26 ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
EchoTools/nevr-runtime#34 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
EchoTools/nevr-runtime#33 ·
All issues in EchoTools/nevr-runtime
Similar issues
-
feature request
Difficulty 1/5 Under an hour Newbie friendliness 86/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
FujiNetWIFI/fujinet-firmware#1730 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
Difficulty 1/5 Under an hour Newbie friendliness 92/100
-
category:port-update
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 2 days