Stage 17 round 6 (#16/#17, PR C): lobby sort + server-derived in-game friend state
CI / changes (pull_request) Successful in 2s
CI / unit (pull_request) Successful in 8s
CI / integration (pull_request) Successful in 11s
CI / ui (pull_request) Successful in 31s
CI / gate (pull_request) Successful in 0s
CI / deploy (pull_request) Successful in 1m19s
CI / changes (pull_request) Successful in 2s
CI / unit (pull_request) Successful in 8s
CI / integration (pull_request) Successful in 11s
CI / ui (pull_request) Successful in 31s
CI / gate (pull_request) Successful in 0s
CI / deploy (pull_request) Successful in 1m19s
Lobby: group the my-games list into your-turn / opponent-turn / finished (empty sections hidden), ordered by last activity (your-turn oldest-first, the other two newest-first), as a compact line-separated list. gameDTO and FB GameView gain last_activity_unix (turn start while active, finish time once finished); a pure lib/lobbysort.ts holds the grouping/ordering. Friends: the in-game 'add to friends' item is now server-derived via a new GET /user/friends/outgoing (+ friends.outgoing op), returning addressees with a pending OR declined request (both read as 'request sent'), so it is correct across reloads; it shows a disabled '✓ in friends' once accepted. It live-updates when the opponent answers: RespondFriendRequest now publishes friend_added (accept) / friend_declined (new notify sub-kind, decline) to the original requester, whose open game re-derives its friend state. Tests: lobbysort unit test; gateway outgoing + last_activity transcode tests; backend integration ListOutgoingRequests + respond-publishes-to-requester; e2e updated for the new lobby section labels + a non-friend active opponent. Docs: ARCHITECTURE notify catalog, FUNCTIONAL(+ru) lobby/friends, PLAN.
This commit is contained in:
+13
-2
@@ -66,6 +66,9 @@ table GameView {
|
||||
move_count:int;
|
||||
end_reason:string;
|
||||
seats:[SeatView];
|
||||
// last_activity_unix is the lobby sort key: the current turn's start for an active
|
||||
// game, the finish time for a finished one (Stage 17).
|
||||
last_activity_unix:long;
|
||||
}
|
||||
|
||||
// MoveRecord is one decoded move (a committed play, or a hint preview).
|
||||
@@ -389,6 +392,13 @@ table IncomingRequestList {
|
||||
requests:[AccountRef];
|
||||
}
|
||||
|
||||
// OutgoingRequestList is the accounts the caller has already requested and cannot
|
||||
// (re-)request: a live pending request or one the addressee declined. The game's
|
||||
// "add to friends" item reads it to stay disabled across reloads (Stage 17).
|
||||
table OutgoingRequestList {
|
||||
requests:[AccountRef];
|
||||
}
|
||||
|
||||
// FriendCode is a freshly issued one-time add-a-friend code (returned once).
|
||||
table FriendCode {
|
||||
code:string;
|
||||
@@ -492,8 +502,9 @@ table MatchFoundEvent {
|
||||
|
||||
// NotificationEvent is a lightweight "something changed, re-poll" signal that
|
||||
// drives the lobby badge (incoming friend requests, invitations). kind is a sub-
|
||||
// discriminator ("friend_request", "friend_added", "invitation", "game_started");
|
||||
// the client re-fetches its lobby counters on any of them.
|
||||
// discriminator ("friend_request", "friend_added", "friend_declined", "invitation",
|
||||
// "game_started"); the client re-fetches its lobby counters (and, for a requester
|
||||
// watching a game, its friend state) on any of them.
|
||||
table NotificationEvent {
|
||||
kind:string;
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user