History Service

[samuelim01]

Description

Create history service with API endpoints, consumers, and basic tests.

Checklist

• I have updated documentation
• All tests passing

Screenshots (if applicable)

[LimZiJia]

LGTM. Works on my end. Just a few questions because I am unfamiliar

The most confusing part is the naming of closeRoomController and updateUserStatusInRoomController in collaboration controller, because they don't say its close because of success and update because of forfeit. Maybe could make use of in-line comments?

[LimZiJia]

Is this because different users from the same room can have different status? If not why not update both users at once instead of sending two messages

[limcaaarl]

User1 can forfeit while User2 can continue on with coding, so we had to separate it out with isForfeit status (according to the user) and roomStatus to indicate whether the room still has a remaining user. I guess the data representation is not so good now that I think about it😅😅as you'll have to check if room is close and check for forfeits at the same time to tell whether the room was closed due to forfeit or successful submission.
Eg; user1-> isForfeit = true, user2 -> isForfeit = true and room is closed would mean that the match ended because both users forfeited.

[samuelim01]

yep, one user could forfeit and the other could submit. A lil funny but I think it does make sense

[LimZiJia]

I am not too sure, but is (err, user) the decoded jwt token? user is the normal schema from user service something like {username: , email: , hashedpasswrd, id: , isAdmin: , create_at,}?

The parsing with zod seems cool.

[samuelim01]

yep so (err, user) would probably be written better as (err, payload), where payload is the decoded jwt token payload and err would be present if there were any issues parsing the jwt token such as invalid format or past the expiry time. Frankly I'm not too sure if userSchema is the full schema of what's in the payload object, but the nice thing is zod does parsing (validate + filter to keep only the fields you specify) instead of just validation.

Here's how the accessToken is generated in the user service:

const accessToken = jwt.sign(
            {
                id: user.id,
                username: user.username,
                role,
            },
            config.JWT_SECRET,
            {
                expiresIn: '1d',
            },
        );

[samuelim01]

LGTM. Works on my end. Just a few questions because I am unfamiliar

The most confusing part is the naming of closeRoomController and updateUserStatusInRoomController in collaboration controller, because they don't say its close because of success and update because of forfeit. Maybe could make use of in-line comments?

@KhoonSun47 could you add some inline comments for closeRoomController and updateUserStatusInRoomController to give the reader an idea of when the functions are used?