NullPointerException in MESSENGER_ACCEPTBUDDY when accepting valid request from offline (or session-mismatched) user

[joshholly]

When User B accepts a buddy request from User A via MESSENGER_ACCEPTBUDDY, Kepler NPEs in MessengerUser's constructor because PlayerManager.getMessengerData() returned a null PlayerDetails for User A.
This happens even when:

Both users exist in the users table
A valid messenger_requests row exists pointing from User A to User B
(potentially) when User A is not currently online

java.lang.NullPointerException: Cannot invoke "PlayerDetails.getId()" because "details" is null
  at MessengerUser.<init>(MessengerUser.java:20)
  at Messenger.<init>(Messenger.java:36)
  at PlayerManager.getMessengerData(PlayerManager.java:133)
  at MESSENGER_ACCEPTBUDDY.acceptBuddy(MESSENGER_ACCEPTBUDDY.java:35)
  at MESSENGER_ACCEPTBUDDY.handle(MESSENGER_ACCEPTBUDDY.java:22)

Suggested fix: null-check details in getMessengerData (or fall back to loading from database when offline). Also possibly null-check in MessengerUser's constructor to fail gracefully rather than NPE.
Reproducible on Kepler v1.6, with a fresh database having only two users (the requester and the recipient).

[Quackster]

We already do offline/online checking when getting messenger/player data and fallback here:

https://github.com/Quackster/Kepler/blob/master/Kepler-Server/src/main/java/org/alexdev/kepler/game/player/PlayerManager.java#L126

https://github.com/Quackster/Kepler/blob/master/Kepler-Server/src/main/java/org/alexdev/kepler/game/player/PlayerManager.java#L100

I cannot reproduce your problem.

[joshholly]

We already do offline/online checking when getting messenger/player data and fallback here:

https://github.com/Quackster/Kepler/blob/master/Kepler-Server/src/main/java/org/alexdev/kepler/game/player/PlayerManager.java#L126

https://github.com/Quackster/Kepler/blob/master/Kepler-Server/src/main/java/org/alexdev/kepler/game/player/PlayerManager.java#L100

I cannot reproduce your problem.

Got the bug to reproduce reliably and captured server logs. The NPE
is happening — the offline/online fallback in getMessengerData
isn't catching this case.

Setup: Kepler v1.6 + MariaDB. Two users — WaffleHacker (id=6, rank 7)
and MOD-TrainReq (id=9, rank 7). Both registered through the in-game
flow, no manual SQL inserts on these accounts.

Step 0 (clean state): both messenger_requests and messenger_friends empty.

Step 1: MOD-TrainReq sends friend request to WaffleHacker. DB shows:

mysql> SELECT * FROM messenger_requests;
+---------+-------+
| from_id | to_id |
+---------+-------+
|       9 |     6 |
+---------+-------+

One row. Correct.

Step 2: Log in as WaffleHacker, open messenger. UI shows
2 pending requests from MOD-TrainReq despite only 1 row in DB.
The request is being delivered/rendered twice.

Step 3: Click accept on first request. Server logs:

2026-05-09T04:14:03.072 ERROR [ErrorLogger] - Error occurred when handling (37) for user (WaffleHacker):
java.lang.NullPointerException: Cannot invoke "org.alexdev.kepler.game.player.PlayerDetails.getId()" because "details" is null
        at org.alexdev.kepler.game.messenger.MessengerUser.<init>(MessengerUser.java:20)
        at org.alexdev.kepler.game.messenger.Messenger.<init>(Messenger.java:36)
        at org.alexdev.kepler.game.player.PlayerManager.getMessengerData(PlayerManager.java:133)
        at org.alexdev.kepler.messages.incoming.messenger.MESSENGER_ACCEPTBUDDY.acceptBuddy(MESSENGER_ACCEPTBUDDY.java:35)
        at org.alexdev.kepler.messages.incoming.messenger.MESSENGER_ACCEPTBUDDY.handle(MESSENGER_ACCEPTBUDDY.java:22)

DB after:

messenger_requests: still 1 row (9 → 6) — accept didn't consume it
messenger_friends: empty — accept didn't create the friendship

Step 4: Click accept on the second (duplicated) request. Same NPE
fires again at 04:21:33. DB still unchanged.

Step 5: Both users in same room. Clicking MOD-TrainReq's avatar
shows "Ask to be friend" — UI doesn't reflect the pending request.

Step 6: WaffleHacker's messenger friends list: empty.

So three issues:

1. Friend request packet duplication on retrieval (1 DB row → 2 UI requests)
2. NPE in MessengerUser's constructor when PlayerDetails is null
3. As a consequence of (2), accept silently fails — request row stays, no friendship created

Re: the offline/online fallback at PlayerManager.java:100 and
:126 — when this NPE fires, MOD-TrainReq is currently logged in (sent
the request seconds before), then logs out before WaffleHacker's accept.
So the path going through the online lookup loses them mid-operation,
and the offline fallback either isn't reached or isn't fully populating
PlayerDetails.

Suggestion: null-check details in MessengerUser's constructor
itself so the operation can't NPE — and treat null-details as "fail
the accept gracefully" rather than crashing the handler. Also worth
investigating why getMessengerData returns a Messenger with null
details rather than just falling back to offline lookup.

Hotel is at https://habbo.wafflehacker.dev/ if it would help to test
against. Happy to provide MariaDB access for diagnostics.

[Quackster]

I don't understand, there's no such thing as Kepler v1.6, where is that from?

[carloselxabi-jpg]

lol