Fix #2037
Fix #2037
Conversation
|
Important Review skippedMore than 25% of the files skipped due to max files limit. The review is being skipped to prevent a low-quality review. 167 files out of 283 files are above the max files limit of 100. Please upgrade to Pro plan to get higher limits. You can disable this status message by setting the WalkthroughWalkthroughThe recent changes introduce significant enhancements to a Node.js project, streamlining CI processes and improving test coverage reporting. Key updates include a refined GitHub Actions workflow, new configuration files for Vite and Vitest, and the addition of several new message handling functions in the game messaging system. These changes collectively enhance the modularity, maintainability, and functionality of the codebase, while also ensuring better organization and clarity for developers. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Server
participant Database
User->>Server: Send Login Request
Server->>Database: Validate User Credentials
Database-->>Server: Return Validation Result
alt Validation Success
Server-->>User: Send Login Success Message
else Validation Failure
Server-->>User: Send Login Failure Message
end
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configuration File (
|
Codecov ReportAttention: Patch coverage is
✅ All tests successful. No failed tests found.
Additional details and impacted files@@ Coverage Diff @@
## dev #2037 +/- ##
==========================================
- Coverage 38.93% 30.08% -8.85%
==========================================
Files 88 207 +119
Lines 9618 9033 -585
Branches 122 349 +227
==========================================
- Hits 3745 2718 -1027
- Misses 5873 6315 +442
*This pull request uses carry forward flags. Click here to find out more. ☔ View full report in Codecov by Sentry. |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
![github-advanced-security[bot]](https://github.com/avatars/in/57789?s=60&v=4){kind=small}
![coderabbitai[bot]](https://github.com/avatars/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 77
Outside diff range, codebase verification and nitpick comments (29)
packages/nps/gameMessageProcessors/processPing.ts (1)
1-22: Function implementation is clear and concise.The
processPingfunction is well-implemented, with appropriate logging and acknowledgment handling. The use of async/await is correct, although the explicitPromise.resolve()at the end is unnecessary since the function is already async.Consider removing the explicit
Promise.resolve():- return Promise.resolve(); + return;packages/shard/package.json (1)
1-27: Package.json configuration is solid.The package.json file is well-configured, with useful scripts and a clear structure. Ensure that all necessary metadata, such as author and keywords, are filled in for completeness.
Consider adding more metadata for better package documentation.
packages/cli/package.json (1)
2-3: Consider adding author information.The
authorfield is currently empty. Adding author information can help with package documentation and maintenance.Also applies to: 18-18
packages/gateway/package.json (1)
2-3: Consider adding author information.The
authorfield is currently empty. Adding author information can help with package documentation and maintenance.Also applies to: 18-18
packages/nps/gameMessageProcessors/processGetFirstBuddy.ts (1)
32-37: Clarify the purpose ofoutMessageinitialization.The initialization of
outMessagewith a specific header ID and data size is not explained. Adding comments or documentation could improve understanding.Add a comment explaining why the header ID
0x614and data size4are used.packages/nps/src/utils/pureCompare.ts (1)
1-48: Enhance documentation for utility functions.While the functions are straightforward, adding more detailed comments or examples could improve clarity and usability.
Consider adding examples of usage for each function in the comments.
packages/nps/messageStructs/UserInfo.ts (1)
4-6: Enhance documentation forUserInfoclass properties.The properties of the
UserInfoclass have brief comments, but more detailed documentation could improve clarity.Consider adding more detailed descriptions for each property, including their purpose and constraints.
packages/shared-packets/src/BasePacket.ts (2)
7-11: Optimize hex conversion logic.The
_asHexmethod appends "0" if the byte length is odd. Consider using a more efficient approach if performance is critical.
13-19: Improve error message clarity.The error message in
_assertEnoughDatais clear, but consider including the actual data length for additional context.- `Data is too short. Expected at least ${expected} bytes, got ${data.length} bytes`, + `Data is too short. Expected at least ${expected} bytes, but received ${data.length} bytes`,packages/nps/gameMessageProcessors/processSelectPersona.ts (1)
25-28: Enhance logging with structured data.The logging statements could benefit from structured logging to improve searchability and analysis.
- log.info(`Customer ID: ${customerId}`); + log.info('Customer ID', { customerId });packages/nps/src/utils/pureGet.ts (1)
56-58: Consider using a boolean type ingetShortBool.The function reads a 2-byte boolean from a buffer. Consider using a boolean type for clarity and consistency.
Consider changing the return type to
booleanfor clarity.packages/nps/services/token.ts (1)
21-24: Validate customer ID ingenerateToken.The function throws an error if
customerIdis not a number. Ensure that this validation is sufficient and consider using a more descriptive error message.Consider improving the error message for clarity:
throw new Error("Customer ID must be a valid number");packages/nps/gameMessageProcessors/processGetProfileInfo.ts (1)
39-39: Consider removing debug log.The log statement is marked with a TODO to be removed. Consider removing or replacing it with a more appropriate log level.
Remove or update the log statement as needed:
// log.info(`GetProfileInfo: ${profile.toString()}`); // TODO: Remove this linepackages/nps/messageStructs/MiniUserList.ts (1)
67-69: Clarify the byte size calculation inMiniUserList.The calculation starts with 16, which may not be immediately clear. Consider breaking down the calculation or adding comments for clarity.
Add comments to explain the initial byte size value and its components.
packages/mcots/messageProcessors/processStockCarInfo.ts (1)
17-100: Lack of Test Coverage forprocessStockCarInfoFunctionThe
processStockCarInfofunction is not covered by any test cases in the current codebase. It is important to add tests to ensure that all branches and edge cases are handled correctly, especially regarding inventory limits and car processing.Analysis chain
Message processing logic in
processStockCarInfo.The function processes stock car info messages and logs relevant details. Ensure that all branches and edge cases are covered, especially regarding inventory limits and car processing.
However, note that this function is not covered by tests.
Run the following script to verify the test coverage for this function:
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify test coverage for `processStockCarInfo`. # Test: Search for test cases covering `processStockCarInfo`. Expect: Adequate test coverage. rg --type ts -A 5 $'processStockCarInfo'Length of output: 2098
Script:
#!/bin/bash # Search for test files in the repository and check for references to `processStockCarInfo`. fd --type f --extension ts --exec rg 'processStockCarInfo' {}Length of output: 332
packages/nps/gameMessageProcessors/index.ts (2)
26-30: Enhance error message clarity inMessageProcessorError.The
MessageProcessorErrorclass provides error messages but could include more context, such as the function or module where the error occurred, to aid in debugging.constructor(id: number, message: string, context?: string) { super(`MessageProcessorError: ${id}: ${context ? context + ': ' : ''}${message}`); }
60-71: Improve error handling inPortMapError.The
PortMapErrorclass could benefit from additional context in its error messages, such as the function or operation that triggered the error.constructor(port: number, message: string, context?: string) { super(`${context ? context + ': ' : ''}${message}`); this.name = "PortMapError"; this.port = port; }packages/mcots/payloads/StockCar.ts (1)
18-30: Ensure error handling inserializemethod.The
serializemethod inStockCarcatches errors but rethrows them without additional context. Consider adding more context to the error message to aid debugging.catch (error) { log.error(`Error serializing StockCar with ID ${this.brandedPartId}: ${error as string}`); throw new Error(`Serialization error for StockCar with ID ${this.brandedPartId}`); }packages/nps/messageStructs/UserAction.ts (2)
37-49: Add error context indeserializemethod.The
deserializemethod catches errors but rethrows them without additional context. Consider adding more context to the error message to aid debugging.catch (error) { log.error(`Error deserializing UserAction for ${this.name}: ${error as string}`); throw new Error(`Deserialization error for UserAction: ${this.name}`); }
81-102: Ensure optional parameters are handled correctly insetmethod.The
setmethod uses default values for optional parameters. Ensure that this logic is correct and consider using more explicit checks for undefined values.this._endTimeMaybe = endTimeMaybe !== undefined ? endTimeMaybe : 0; this._b1 = b1 !== undefined ? b1 : 0; this._b2 = b2 !== undefined ? b2 : 0;packages/nps/messageStructs/UserStatus.ts (2)
6-12: Consider initializing properties in the constructor.While default values are set for class properties, consider initializing them directly within the constructor to enhance clarity and maintainability.
124-134: Clarify the calculation ingetSizemethod.The
getSizemethod includes some hardcoded values. Consider documenting or clarifying why these specific values are used to improve maintainability.packages/nps/messageStructs/GameMessage.ts (1)
45-51: Consider using constants for buffer sizes.In
serializeV0, the buffer size is determined bygetByteSize. Consider using constants or comments to clarify the expected size, enhancing readability.packages/mcots/payloads/LoginCompleteMessage.ts (2)
31-33: Clarify byte size calculation ingetByteSize.The
getByteSizemethod uses a hardcoded value. Consider documenting the calculation or using constants for clarity and maintainability.
35-75: Improve error handling indeserialize.The
deserializemethod logs errors but rethrows them. Consider providing more context in the error message or handling specific error types.packages/nps/messageStructs/GameProfile.ts (1)
32-53: Consider initializing properties in the constructor.While default values are set for class properties, consider initializing them directly within the constructor to enhance clarity and maintainability.
packages/shared-packets/src/ServerMessage.ts (3)
139-152: Enhance error logging inserialize.Consider including more context in the error log, such as the message ID, to aid in debugging.
Enhance the logging as follows:
log.error( - `Error serializing ServerGenericRequest: ${error as string}`, + `Error serializing ServerGenericRequest with messageId ${this.messageId}: ${error as string}`, );
155-169: Enhance error logging indeserialize.Consider including more context in the error log, such as the message ID, to aid in debugging.
Enhance the logging as follows:
log.error( - `Error deserializing ServerGenericRequest: ${error as string}`, + `Error deserializing ServerGenericRequest with messageId ${this.messageId}: ${error as string}`, );
273-299: Add validation checks before serialization.Consider adding checks to ensure that
datais not null and thatheaderfields are properly initialized.Add validation checks as follows:
if (!this.data) { throw new Error("ServerMessage data is not set before serializing"); } if (!this.header) { throw new Error("ServerMessage header is not set before serializing"); }
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
Files selected for processing (94)
- .github/workflows/node.yml (2 hunks)
- .gitignore (1 hunks)
- .npmrc (1 hunks)
- .nvmrc (1 hunks)
- Makefile (1 hunks)
- apps/main/package.json (1 hunks)
- package.json (2 hunks)
- packages/cli/package.json (1 hunks)
- packages/cli/test/index.test.ts (1 hunks)
- packages/cli/vite.config.ts (1 hunks)
- packages/database/package.json (1 hunks)
- packages/database/vite.config.ts (1 hunks)
- packages/gateway/package.json (1 hunks)
- packages/gateway/vite.config.ts (1 hunks)
- packages/mcots/ClientConnectionManager.ts (1 hunks)
- packages/mcots/errors/ErrorNoKey.ts (1 hunks)
- packages/mcots/index.ts (1 hunks)
- packages/mcots/messageProcessors/index.ts (1 hunks)
- packages/mcots/messageProcessors/processClientConnect.ts (1 hunks)
- packages/mcots/messageProcessors/processClientTracking.ts (1 hunks)
- packages/mcots/messageProcessors/processServerLogin.ts (1 hunks)
- packages/mcots/messageProcessors/processSetOptions.ts (1 hunks)
- packages/mcots/messageProcessors/processStockCarInfo.ts (1 hunks)
- packages/mcots/messageProcessors/sendSuccess.ts (1 hunks)
- packages/mcots/package.json (1 hunks)
- packages/mcots/payloads/ClientConnectMessage.ts (1 hunks)
- packages/mcots/payloads/ClientTrackingMessage.ts (1 hunks)
- packages/mcots/payloads/LoginCompleteMessage.ts (1 hunks)
- packages/mcots/payloads/LoginMessage.ts (1 hunks)
- packages/mcots/payloads/SetOptionsMessage.ts (1 hunks)
- packages/mcots/payloads/StockCar.ts (1 hunks)
- packages/mcots/payloads/index.ts (1 hunks)
- packages/mcots/test/index.test.ts (1 hunks)
- packages/mcots/vite.config.ts (1 hunks)
- packages/nps/gameMessageProcessors/getLobMiniRiffList.ts (1 hunks)
- packages/nps/gameMessageProcessors/getLobMiniUserList.ts (1 hunks)
- packages/nps/gameMessageProcessors/index.ts (1 hunks)
- packages/nps/gameMessageProcessors/lobbyCommands.ts (1 hunks)
- packages/nps/gameMessageProcessors/processCheckPlateText.ts (1 hunks)
- packages/nps/gameMessageProcessors/processCheckProfileName.ts (1 hunks)
- packages/nps/gameMessageProcessors/processCreateProfile.ts (1 hunks)
- packages/nps/gameMessageProcessors/processDeleteProfile.ts (1 hunks)
- packages/nps/gameMessageProcessors/processEncryptedGameCommand.ts (1 hunks)
- packages/nps/gameMessageProcessors/processGameLogin.ts (1 hunks)
- packages/nps/gameMessageProcessors/processGameLogout.ts (1 hunks)
- packages/nps/gameMessageProcessors/processGetFirstBuddy.ts (1 hunks)
- packages/nps/gameMessageProcessors/processGetProfileInfo.ts (1 hunks)
- packages/nps/gameMessageProcessors/processGetProfileMaps.ts (1 hunks)
- packages/nps/gameMessageProcessors/processPing.ts (1 hunks)
- packages/nps/gameMessageProcessors/processSelectPersona.ts (1 hunks)
- packages/nps/gameMessageProcessors/processUserLogin.ts (1 hunks)
- packages/nps/index.ts (1 hunks)
- packages/nps/messageStructs/GameMessage.ts (1 hunks)
- packages/nps/messageStructs/GameProfile.ts (1 hunks)
- packages/nps/messageStructs/MiniRiffList.ts (1 hunks)
- packages/nps/messageStructs/MiniUserList.ts (1 hunks)
- packages/nps/messageStructs/NPSList.ts (1 hunks)
- packages/nps/messageStructs/ProfileList.ts (1 hunks)
- packages/nps/messageStructs/SessionKey.ts (1 hunks)
- packages/nps/messageStructs/UserAction.ts (1 hunks)
- packages/nps/messageStructs/UserInfo.ts (1 hunks)
- packages/nps/messageStructs/UserStatus.ts (1 hunks)
- packages/nps/package.json (1 hunks)
- packages/nps/services/account.ts (1 hunks)
- packages/nps/services/profile.ts (1 hunks)
- packages/nps/services/token.ts (1 hunks)
- packages/nps/services/types.ts (1 hunks)
- packages/nps/src/EncryptionSession.ts (1 hunks)
- packages/nps/src/UserStatusManager.ts (1 hunks)
- packages/nps/src/utils/pureCompare.ts (1 hunks)
- packages/nps/src/utils/pureGet.ts (1 hunks)
- packages/nps/src/utils/purePut.ts (1 hunks)
- packages/nps/src/utils/sendNPSAck.ts (1 hunks)
- packages/nps/test/index.test.ts (1 hunks)
- packages/nps/types.ts (1 hunks)
- packages/nps/vite.config.ts (1 hunks)
- packages/patch/package.json (1 hunks)
- packages/patch/vite.config.ts (1 hunks)
- packages/shard/package.json (1 hunks)
- packages/shard/vite.config.ts (1 hunks)
- packages/shared-packets/index.ts (1 hunks)
- packages/shared-packets/package.json (1 hunks)
- packages/shared-packets/src/BasePacket.ts (1 hunks)
- packages/shared-packets/src/ServerMessage.ts (1 hunks)
- packages/shared-packets/src/interfaces.ts (1 hunks)
- packages/shared-packets/src/utils.ts (1 hunks)
- packages/shared-packets/test/index.test.ts (1 hunks)
- packages/shared-packets/tsconfig.json (1 hunks)
- packages/shared-packets/vite.config.ts (1 hunks)
- packages/shared/index.ts (1 hunks)
- packages/shared/package.json (1 hunks)
- packages/shared/vite.config.ts (1 hunks)
- server.ts (2 hunks)
- tsconfig.json (1 hunks)
Files skipped from review due to trivial changes (12)
- .gitignore
- .npmrc
- packages/cli/test/index.test.ts
- packages/database/vite.config.ts
- packages/mcots/package.json
- packages/mcots/test/index.test.ts
- packages/nps/test/index.test.ts
- packages/patch/package.json
- packages/shared-packets/index.ts
- packages/shared-packets/test/index.test.ts
- packages/shared/package.json
- tsconfig.json
Additional context used
GitHub Check: codecov/patch
packages/mcots/errors/ErrorNoKey.ts
[warning] 2-5: packages/mcots/errors/ErrorNoKey.ts#L2-L5
Added lines #L2 - L5 were not covered by testspackages/mcots/payloads/index.ts
[warning] 2-8: packages/mcots/payloads/index.ts#L2-L8
Added lines #L2 - L8 were not covered by testspackages/nps/gameMessageProcessors/lobbyCommands.ts
[warning] 2-15: packages/nps/gameMessageProcessors/lobbyCommands.ts#L2-L15
Added lines #L2 - L15 were not covered by testspackages/nps/gameMessageProcessors/processGameLogout.ts
[warning] 2-15: packages/nps/gameMessageProcessors/processGameLogout.ts#L2-L15
Added lines #L2 - L15 were not covered by testspackages/mcots/messageProcessors/sendSuccess.ts
[warning] 2-17: packages/mcots/messageProcessors/sendSuccess.ts#L2-L17
Added lines #L2 - L17 were not covered by testspackages/mcots/index.ts
[warning] 2-18: packages/mcots/index.ts#L2-L18
Added lines #L2 - L18 were not covered by testspackages/nps/gameMessageProcessors/getLobMiniUserList.ts
[warning] 2-28: packages/nps/gameMessageProcessors/getLobMiniUserList.ts#L2-L28
Added lines #L2 - L28 were not covered by testspackages/mcots/messageProcessors/processClientTracking.ts
[warning] 2-27: packages/mcots/messageProcessors/processClientTracking.ts#L2-L27
Added lines #L2 - L27 were not covered by testspackages/mcots/messageProcessors/processSetOptions.ts
[warning] 2-27: packages/mcots/messageProcessors/processSetOptions.ts#L2-L27
Added lines #L2 - L27 were not covered by testspackages/nps/gameMessageProcessors/processCheckPlateText.ts
[warning] 2-33: packages/nps/gameMessageProcessors/processCheckPlateText.ts#L2-L33
Added lines #L2 - L33 were not covered by testspackages/nps/gameMessageProcessors/processCheckProfileName.ts
[warning] 2-33: packages/nps/gameMessageProcessors/processCheckProfileName.ts#L2-L33
Added lines #L2 - L33 were not covered by testspackages/mcots/payloads/ClientTrackingMessage.ts
[warning] 2-44: packages/mcots/payloads/ClientTrackingMessage.ts#L2-L44
Added lines #L2 - L44 were not covered by testspackages/nps/gameMessageProcessors/getLobMiniRiffList.ts
[warning] 2-40: packages/nps/gameMessageProcessors/getLobMiniRiffList.ts#L2-L40
Added lines #L2 - L40 were not covered by testspackages/mcots/messageProcessors/processServerLogin.ts
[warning] 2-35: packages/mcots/messageProcessors/processServerLogin.ts#L2-L35
Added lines #L2 - L35 were not covered by testspackages/nps/gameMessageProcessors/processGetFirstBuddy.ts
[warning] 2-44: packages/nps/gameMessageProcessors/processGetFirstBuddy.ts#L2-L44
Added lines #L2 - L44 were not covered by testspackages/nps/gameMessageProcessors/processCreateProfile.ts
[warning] 2-45: packages/nps/gameMessageProcessors/processCreateProfile.ts#L2-L45
Added lines #L2 - L45 were not covered by testspackages/mcots/messageProcessors/index.ts
[warning] 2-39: packages/mcots/messageProcessors/index.ts#L2-L39
Added lines #L2 - L39 were not covered by testspackages/mcots/ClientConnectionManager.ts
[warning] 2-49: packages/mcots/ClientConnectionManager.ts#L2-L49
Added lines #L2 - L49 were not covered by testspackages/nps/gameMessageProcessors/processGetProfileInfo.ts
[warning] 2-66: packages/nps/gameMessageProcessors/processGetProfileInfo.ts#L2-L66
Added lines #L2 - L66 were not covered by testspackages/mcots/payloads/ClientConnectMessage.ts
[warning] 2-72: packages/mcots/payloads/ClientConnectMessage.ts#L2-L72
Added lines #L2 - L72 were not covered by testspackages/mcots/payloads/SetOptionsMessage.ts
[warning] 2-78: packages/mcots/payloads/SetOptionsMessage.ts#L2-L78
Added lines #L2 - L78 were not covered by testspackages/mcots/payloads/LoginMessage.ts
[warning] 2-86: packages/mcots/payloads/LoginMessage.ts#L2-L86
Added lines #L2 - L86 were not covered by testspackages/mcots/messageProcessors/processClientConnect.ts
[warning] 2-86: packages/mcots/messageProcessors/processClientConnect.ts#L2-L86
Added lines #L2 - L86 were not covered by testspackages/mcots/messageProcessors/processStockCarInfo.ts
[warning] 2-107: packages/mcots/messageProcessors/processStockCarInfo.ts#L2-L107
Added lines #L2 - L107 were not covered by testspackages/nps/gameMessageProcessors/processDeleteProfile.ts
[warning] 2-109: packages/nps/gameMessageProcessors/processDeleteProfile.ts#L2-L109
Added lines #L2 - L109 were not covered by testspackages/nps/gameMessageProcessors/index.ts
[warning] 2-88: packages/nps/gameMessageProcessors/index.ts#L2-L88
Added lines #L2 - L88 were not covered by testspackages/mcots/payloads/StockCar.ts
[warning] 2-122: packages/mcots/payloads/StockCar.ts#L2-L122
Added lines #L2 - L122 were not covered by testspackages/nps/gameMessageProcessors/processEncryptedGameCommand.ts
[warning] 2-113: packages/nps/gameMessageProcessors/processEncryptedGameCommand.ts#L2-L113
Added lines #L2 - L113 were not covered by testspackages/mcots/payloads/LoginCompleteMessage.ts
[warning] 2-231: packages/mcots/payloads/LoginCompleteMessage.ts#L2-L231
Added lines #L2 - L231 were not covered by testspackages/nps/gameMessageProcessors/processGameLogin.ts
[warning] 2-210: packages/nps/gameMessageProcessors/processGameLogin.ts#L2-L210
Added lines #L2 - L210 were not covered by tests
Biome
packages/nps/index.ts
[error] 21-21: Useless rename.
Safe fix: Remove the renaming.
(lint/complexity/noUselessRename)
GitHub Check: SonarCloud
packages/nps/src/EncryptionSession.ts
[failure] 48-48: Cipher algorithms should be robust
Use a strong cipher algorithm.See more on SonarCloud
[failure] 48-48: Encryption algorithms should be used with secure mode and padding scheme
Use a secure mode and padding scheme.See more on SonarCloud
Additional comments not posted (85)
.nvmrc (1)
1-1: Verify compatibility with Node.js v22.6.0.The update to Node.js version
22.6.0may introduce new features and deprecations. Ensure that the codebase and all dependencies are compatible with this version.Run the following script to check for any deprecated or incompatible features:
packages/nps/services/types.ts (1)
1-18: Type definitions look good.The
PartandVehicletypes are well-defined, providing clear structure and type safety.packages/nps/src/utils/sendNPSAck.ts (1)
4-10: VerifyGameMessageandGameSocketCallbackusage.Ensure that
GameMessageandGameSocketCallbackare correctly implemented and used as intended in the function.Run the following script to verify the implementation of
GameMessageandGameSocketCallback:Verification successful
GameMessageandGameSocketCallbackare correctly implemented and used.
GameMessageis implemented inpackages/nps/messageStructs/GameMessage.tsand correctly initializes its components.GameSocketCallbackis defined as a function taking an array ofBufferobjects, matching its usage insendNPSAck.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the implementation of `GameMessage` and `GameSocketCallback`. # Test: Search for the implementation of `GameMessage`. ast-grep --lang typescript --pattern $'class GameMessage { $$$ }' # Test: Search for the type definition of `GameSocketCallback`. ast-grep --lang typescript --pattern $'type GameSocketCallback = $_'Length of output: 246
Script:
#!/bin/bash # Search for the definition of the `GameMessage` class in the codebase. rg 'class GameMessage' -A 10Length of output: 2288
packages/shared-packets/package.json (1)
1-22: Verify scripts and metadata accuracy.Ensure that the scripts defined in the
package.jsonfile, such ascheck,lint,format, andtest, are functional and correctly configured. Additionally, verify that the metadata, including the package name, version, and license, is accurate and appropriate for your project.Would you like guidance on how to verify and test these configurations?
packages/mcots/messageProcessors/sendSuccess.ts (1)
7-16: LGTM!The
sendSuccessfunction correctly constructs and sends a server response message.apps/main/package.json (1)
1-20: LGTM!The
package.jsonconfiguration is well-structured and aligns with standard Node.js practices.packages/nps/package.json (1)
1-25: LGTM!The
package.jsonconfiguration is well-structured, with a focus on code quality and maintenance.packages/nps/types.ts (1)
1-23: LGTM!The TypeScript interfaces are well-defined and provide clear contracts for serialization and messaging.
packages/cli/vite.config.ts (1)
1-22: Configuration looks good!The configuration for Vitest is well-structured and follows best practices for setting up test coverage and reporting. The use of multiple reporters ensures comprehensive feedback on test results.
packages/gateway/vite.config.ts (1)
1-22: Consistent configuration confirmed!The configuration is consistent with the
clipackage, ensuring uniform test coverage and reporting across different packages.packages/mcots/vite.config.ts (1)
1-22: Configuration consistency maintained!The setup for the
mcotspackage aligns with the other packages, promoting maintainability and ease of understanding.packages/nps/vite.config.ts (1)
1-22: Consistent configuration across packages!The configuration for the
npspackage is consistent with the others, which is excellent for maintaining a standard approach across the project.packages/patch/vite.config.ts (1)
1-22: Configuration consistency upheld!The
patchpackage configuration is in line with the rest, ensuring uniformity in test setup across the project.packages/shard/vite.config.ts (1)
1-22: Configuration looks good.The Vitest configuration is well-structured, enabling coverage and specifying reporters effectively. The exclusion patterns are appropriate for typical test and build files.
packages/shared-packets/vite.config.ts (1)
1-22: Consistent configuration across packages.The Vitest configuration maintains consistency with other packages, which aids in maintainability and ease of understanding.
packages/shared/vite.config.ts (1)
1-22: Standardized configuration is beneficial.The consistent use of Vitest configuration across different packages ensures a standardized testing approach, which is advantageous for the project.
packages/cli/package.json (2)
4-10: Exports and type settings are correct.The exports and type settings align with modern JavaScript module standards.
20-26: Dependencies are appropriate.The listed dependencies and devDependencies seem appropriate for the project.
packages/gateway/package.json (2)
4-10: Exports and type settings are correct.The exports and type settings align with modern JavaScript module standards.
20-29: Dependencies and directories are appropriate.The listed dependencies and the test directory specification seem appropriate for the project.
packages/shared/index.ts (2)
1-8: Module exports are correctly defined.The exports align with the intended module structure and are correctly defined.
10-24: Interface definitions are clear and well-structured.The
KeypressEventandConnectionRecordinterfaces are clearly defined.packages/database/package.json (1)
1-35: LGTM!The
package.jsonfile is well-structured, and the dependencies and scripts are appropriate for the package.Makefile (2)
12-12: Verify the switch topnpmfor testing.The change from
npmtopnpmfor testing indicates a shift in package management.Ensure that all team members are aware of this change and have
pnpminstalled. Verify that the CI/CD pipeline is updated accordingly.
12-12: Verify the impact of removing the build command.The removal of the build command suggests a change in the build process.
Ensure that the build process is handled appropriately elsewhere and that this change aligns with the new workflow.
packages/nps/gameMessageProcessors/processCheckProfileName.ts (1)
10-33: Verify message processing logic.Ensure that the message processing logic, especially the serialization and deserialization of messages, is correct and aligns with the expected protocol.
Run the following script to verify the usage of
processCheckProfileNameand ensure that it aligns with the expected message format:Tools
GitHub Check: codecov/patch
[warning] 2-33: packages/nps/gameMessageProcessors/processCheckProfileName.ts#L2-L33
Added lines #L2 - L33 were not covered by testspackages/mcots/payloads/ClientTrackingMessage.ts (1)
20-34: Verify deserialization logic and error handling.Ensure that the deserialization logic correctly handles the buffer data and that error handling is robust.
Run the following script to verify the deserialization logic and error handling in
ClientTrackingMessage:Verification successful
Deserialization Logic and Error Handling Verified
The deserialization logic in
ClientTrackingMessagecorrectly handles buffer data by reading specific positions and assigning them to class properties. The error handling logs the error and rethrows it, ensuring that issues are not silently ignored. The usage inprocessClientTracking.tsconfirms that the deserialization method is invoked correctly and the data is used appropriately.
processClientTracking.ts: Demonstrates the usage ofdeserializeand subsequent handling of deserialized data.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the deserialization logic and error handling in `ClientTrackingMessage`. # Test: Search for the class usage. Expect: Correct buffer handling and error logging. rg --type typescript -A 5 $'ClientTrackingMessage'Length of output: 84
Script:
#!/bin/bash # Corrected search for the class usage in TypeScript files. rg --glob '*.ts' -A 5 'ClientTrackingMessage'Length of output: 3773
packages/nps/gameMessageProcessors/getLobMiniRiffList.ts (1)
12-39: Verify message creation and serialization logic.Ensure that the message creation and serialization logic correctly follows the expected protocol and data structure.
Run the following script to verify the message creation and serialization logic in
getLobMiniRiffList:Verification successful
Message creation and serialization logic verified.
The
getLobMiniRiffListfunction correctly implements the message creation and serialization logic. TheGameMessageandMiniRiffListclasses are structured to handle serialization as expected. TheMiniRiffListis serialized and set as data in theGameMessage, aligning with the protocol requirements.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the message creation and serialization logic in `getLobMiniRiffList`. # Test: Search for the function usage. Expect: Correct message creation and serialization. rg --type typescript -A 5 $'getLobMiniRiffList'Length of output: 81
Script:
#!/bin/bash # Correcting the file type and searching for the function usage. rg --type ts -A 5 $'getLobMiniRiffList' # Searching for the implementation of GameMessage to verify serialization logic. ast-grep --lang typescript --pattern $'class GameMessage { $$$ }' # Searching for the implementation of MiniRiffList to verify its structure. ast-grep --lang typescript --pattern $'class MiniRiffList { $$$ }'Length of output: 2415
Script:
#!/bin/bash # Searching for the implementation of GameMessage to verify serialization logic. rg 'class GameMessage' -A 10 # Searching for the implementation of MiniRiffList to verify its structure. rg 'class MiniRiffList' -A 10Length of output: 3164
packages/mcots/messageProcessors/processServerLogin.ts (1)
8-34: Verify login message processing logic.Ensure that the login message processing logic, especially the deserialization and response creation, is correct and aligns with the expected protocol.
Run the following script to verify the usage of
processServerLoginand ensure that it aligns with the expected message format:packages/nps/src/utils/pureCompare.ts (1)
35-37: Consider edge cases forareBothUndefined.The function checks if both values are undefined, but consider scenarios where the inputs might not be of type
unknown.Ensure that the function handles all possible input types correctly. If necessary, add type checks or constraints.
packages/shared-packets/src/BasePacket.ts (2)
4-33: Ensure interface implementation correctness.The
Serializableclass implements theISerializableinterface. Verify that all required methods from the interface are correctly implemented.Run the following script to verify the interface implementation:
35-48: Ensure correct header handling inBasePacket.The
BasePacketclass manages a header and extendsSerializable. Verify that the header is correctly serialized and deserialized.Run the following script to ensure correct header handling:
packages/mcots/ClientConnectionManager.ts (1)
3-11: Verify singleton pattern implementation.The
ClientConnectionManagerclass uses a singleton pattern. Ensure that the pattern is correctly implemented and thread-safe.Run the following script to verify the singleton pattern:
Verification successful
Singleton Pattern Correctly Implemented
The
ClientConnectionManagerclass correctly implements the singleton pattern by controlling instantiation through thegetInstancemethod. There are no other direct instantiations found in the codebase. Given the typical single-threaded nature of JavaScript environments, additional thread safety measures are not necessary unless explicitly required.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify singleton pattern implementation in `ClientConnectionManager`. # Test: Search for multiple instantiations of `ClientConnectionManager`. rg --type typescript -A 5 $'new ClientConnectionManager'Length of output: 92
Script:
#!/bin/bash # Description: Verify singleton pattern implementation in `ClientConnectionManager`. # Test: Search for multiple instantiations of `ClientConnectionManager`. rg 'new ClientConnectionManager' --glob '*.ts' -A 5Length of output: 514
packages/nps/src/utils/pureGet.ts (6)
3-6: Ensure buffer safety ingetWord.The function reads a 16-bit word from a buffer. Ensure that the offset is within the bounds of the buffer to prevent runtime errors.
Consider adding a check to ensure the offset is valid:
if (offset < 0 || offset + 2 > bytes.length) { throw new RangeError('Offset is out of bounds'); }
8-11: Ensure buffer safety ingetDWord.The function reads a 32-bit double word from a buffer. Ensure that the offset is within the bounds of the buffer to prevent runtime errors.
Consider adding a check to ensure the offset is valid:
if (offset < 0 || offset + 4 > bytes.length) { throw new RangeError('Offset is out of bounds'); }
17-23: Ensure buffer safety ingetNBytes.The function extracts the first
nbytes from a buffer. Ensure thatnis non-negative and handle edge cases wherenexceeds the buffer length.Consider adding a check to ensure
nis valid:if (n < 0) { throw new RangeError('Number of bytes to get must be non-negative'); }
26-30: Handle odd-length buffers ingetAsHex.The function appends a "0" to hex strings of odd-length buffers. Verify if this behavior is intended and document it if necessary.
Ensure that appending "0" is the desired behavior for odd-length buffers.
32-41: Ensure buffer safety ingetLenString.The function reads a length-prefixed string from a buffer. Ensure that the calculated string length does not exceed the buffer length.
Consider adding a check to ensure the string length is valid:
const strLen = getWord(bytes, offset, isLE); if (offset + 2 + strLen > bytes.length) { throw new RangeError('String length exceeds buffer length'); }
44-53: Ensure buffer safety ingetLenBlob.The function reads a length-prefixed blob from a buffer. Ensure that the calculated blob length does not exceed the buffer length.
Consider adding a check to ensure the blob length is valid:
const blobLen = getDWord(bytes, offset, isLE); if (offset + 2 + blobLen > bytes.length) { throw new RangeError('Blob length exceeds buffer length'); }packages/nps/services/token.ts (3)
12-19: Ensure uniqueness and security of tokens ingenerateTokenRecord.The function generates a token using
uid.stamp(34). Verify that the token length and uniqueness meet security requirements.Ensure that the token generation method provides sufficient randomness and uniqueness.
30-41: Verify token expiration logic inisTokenExpired.The function checks if a token is expired based on a 30-minute window. Ensure that the expiration logic aligns with system requirements.
Confirm that the expiration time of 30 minutes is appropriate for your use case.
62-67: Ensure token validity ingetCustomerId.The function checks if a token is expired before returning the customer ID. Ensure that this logic is consistent with other parts of the system.
Verify that the logic for checking token validity is consistent across the system.
packages/nps/messageStructs/ProfileList.ts (3)
22-25: Ensure consistency inaddProfile.The method updates
maxProfilesafter adding a profile. Ensure that this logic is consistent with the intended use ofmaxProfiles.Verify that updating
maxProfilesafter each addition is the desired behavior.
27-38: Ensure buffer allocation correctness intoBytes.The method allocates a buffer based on
getSize(). Ensure thatgetSize()accurately reflects the required buffer size.Confirm that
getSize()correctly calculates the buffer size needed for serialization.
52-58: Verify size calculation ingetSize.The method calculates the total size of the profiles. Ensure that this calculation is accurate and reflects the actual data structure.
Double-check the size calculation to ensure it matches the expected structure.
packages/nps/gameMessageProcessors/processUserLogin.ts (1)
15-20: Ensure proper error handling for socketCallback.The
socketCallbackfunction is called with the response bytes. Make sure that any errors occurring within this callback are properly handled to prevent unhandled exceptions.Review the implementation of
socketCallbackto ensure it handles errors gracefully. If needed, wrap the call in a try-catch block.packages/nps/gameMessageProcessors/processGetProfileMaps.ts (1)
25-27: Verify the correctness of the new message version.The comment mentions a bug in the client regarding message versioning. Ensure that the new message with version 257 is correctly handled by the client.
Confirm that the client can process messages with the corrected version. If possible, test this change in a staging environment.
packages/mcots/payloads/SetOptionsMessage.ts (1)
29-31: Ensure sufficient data length before deserialization.The
_assertEnoughDatamethod is used to check data length. Ensure this method correctly validates the data size to prevent buffer overflows or underflows.Review the implementation of
_assertEnoughDatato confirm it adequately checks the buffer size.packages/nps/services/profile.ts (1)
59-59: Ensure database operations are error-handled.The
addGameProfilefunction performs a database operation. Ensure that any errors during this operation are caught and handled appropriately.Review the error handling for database operations in
ProfileSchemato ensure robustness.packages/mcots/payloads/LoginMessage.ts (1)
6-85: LGTM! TheLoginMessageclass is well-implemented.The class correctly handles the deserialization of login message payloads and provides necessary getters. The use of logging for error handling is a good practice.
packages/nps/src/utils/purePut.ts (1)
1-105: LGTM! Utility functions are well-implemented.The functions for writing data to buffers in various formats and byte orders are correctly implemented.
packages/nps/src/UserStatusManager.ts (1)
3-79: LGTM! TheUserStatusManagerclass is well-implemented.The class correctly manages user statuses using a singleton pattern and provides necessary methods for status management.
packages/mcots/messageProcessors/processClientConnect.ts (1)
15-84: LGTM! TheprocessClientConnectfunction is well-implemented.The function is well-structured with appropriate logging and error handling for processing client connection requests.
package.json (2)
13-19: LGTM! The script updates enhance the project's workflow.The new scripts for cleaning, starting, testing, and database management streamline the development process.
40-51: LGTM! The introduction of workspaces improves project organization.Defining workspaces for multiple packages enhances modularity and maintainability.
server.ts (3)
36-36: Good practice: Use environment variable for Sentry DSN.The change from a hardcoded DSN to using
process.env.SENTRY_DSNenhances security and flexibility by allowing configuration through environment variables.
62-66: Consistent use of environment variables.The use of environment variables for configuration is consistent and aligns with best practices for managing sensitive data and deployment configurations.
45-57: Ensure environment variables are set.The checks for undefined environment variables are crucial for preventing runtime errors. Ensure these variables are correctly set in all deployment environments.
Run the following script to verify the presence of these environment variables in the codebase:
.github/workflows/node.yml (5)
1-1: Simplified workflow name.Renaming the workflow from "Node.js CI" to "Node.js" simplifies the title and maintains clarity.
27-30: Consolidated install and test step.Combining installation and testing into a single step improves efficiency and reduces complexity in the workflow.
34-34: Always run Codecov step.Using
if: ${{ always() }}ensures that the Codecov step runs regardless of previous job success, which is beneficial for consistent coverage reporting.
10-13: Verify environment variable safety.The environment variables
EXTERNAL_HOST,PRIVATE_KEY_FILE,CERTIFICATE_FILE, andPUBLIC_KEY_FILEare marked as safe to leak. Ensure these are indeed safe and do not contain sensitive information.Run the following script to verify the usage and safety of these environment variables:
Verification successful
Environment Variables Currently Safe
The files referenced by the environment variables
PRIVATE_KEY_FILE,CERTIFICATE_FILE, andPUBLIC_KEY_FILEdo not exist in the repository. Therefore, there is no risk of leaking sensitive information at this time. Ensure that if these files are added in the future, they are properly secured and do not contain sensitive data unless necessary.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the usage and safety of environment variables. # Test: Search for environment variable usage. Expect: No sensitive data should be exposed. rg --type yaml -A 2 $'EXTERNAL_HOST|PRIVATE_KEY_FILE|CERTIFICATE_FILE|PUBLIC_KEY_FILE'Length of output: 419
Script:
#!/bin/bash # Check if the files exist and inspect their contents to determine if they contain sensitive information. # Check for the existence of the files files=("thebeast/data/private_key.pem" "thebeast/data/mcouniverse.crt" "thebeast/data/pub.key") for file in "${files[@]}"; do if [ -f "$file" ]; then echo "File $file exists. Displaying first few lines:" head -n 10 "$file" else echo "File $file does not exist." fi doneLength of output: 619
23-26: Hardcoded Node.js version.The Node.js version is hardcoded to
22.x. Ensure this version is compatible with all parts of the codebase and deployment environments.Run the following script to verify the compatibility of Node.js version
22.x:packages/nps/messageStructs/MiniRiffList.ts (3)
11-24: Constructor validation forriffName.The constructor correctly validates the length of
riffNameand throws an error if it exceeds the maximum allowed length. This is a good practice for data integrity.
50-99: Implementation ofMiniRiffList.The
MiniRiffListclass effectively manages a list ofMiniRiffInfoobjects, providing serialization and size calculation methods. The use of logging for debugging is appropriate.
26-38: Serialization logic inMiniRiffInfo.The
serializemethod correctly allocates a buffer and writes data in a structured format. Ensure thatputLenStringhandles the string encoding as expected.Run the following script to verify the
putLenStringfunction implementation:Verification successful
Serialization logic in
MiniRiffInfois correctly implemented.The
putLenStringfunction handles string encoding and endianness as expected, ensuring proper serialization. No issues were found with its implementation.
putLenStringcorrectly uses UTF-8 encoding and includes a null terminator.- It handles both little-endian and big-endian formats based on the
isLEflag.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the implementation of `putLenString`. # Test: Search for `putLenString` function. Expect: Correct handling of string encoding. ast-grep --lang typescript --pattern 'function putLenString($_, $_, $_, $_) { $$$ }'Length of output: 86
Script:
#!/bin/bash # Search for the definition of `putLenString` function across the codebase. rg 'function putLenString' -A 5 # Search for any imports of `putLenString` in the codebase. rg 'import.*putLenString'Length of output: 660
Script:
#!/bin/bash # Extract the implementation of the `putLenString` function from its definition file. rg 'export function putLenString' -A 20 packages/nps/src/utils/purePut.tsLength of output: 532
packages/nps/messageStructs/SessionKey.ts (4)
12-27: Constructor validation forSessionKey.The constructor correctly checks if both
keyandtimestampare set, ensuring data consistency. The use of logging for debugging is appropriate.
28-30: Serialization method inSessionKey.The
serializemethod returns the result oftoBytes, which is a clear and efficient approach.
81-95: Serialization logic intoBytes.The
toBytesmethod correctly constructs a buffer and writes data in a structured format. Ensure the method handles all edge cases.
38-57: Static methodfromBytes.The
fromBytesmethod correctly reconstructs aSessionKeyfrom a buffer. Ensure the buffer operations are accurate and handle edge cases.Run the following script to verify the buffer operations in
fromBytes:Verification successful
Buffer operations in
fromBytesare accurate.The
fromBytesmethod inSessionKey.tscorrectly handles buffer operations by reading the key length, extracting the key, and reading the timestamp. Ensure the buffer passed to this method is well-formed to prevent errors.
readUInt16BE(0)is used to read the key length.subarray(2, dataOffset)extracts the key.readUInt32BE(dataOffset)reads the timestamp.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify buffer operations in `fromBytes`. # Test: Search for `fromBytes` method. Expect: Accurate buffer operations. ast-grep --lang typescript --pattern 'static fromBytes($_) { $$$ }'Length of output: 520
Script:
#!/bin/bash # Use ripgrep to find the `fromBytes` method and display surrounding lines for context. rg 'static fromBytes' -A 15 --glob '**/*.ts'Length of output: 4963
packages/nps/gameMessageProcessors/processDeleteProfile.ts (1)
19-29: Ensure secure handling of cryptographic operations.The
decryptSessionKeyfunction usescrypto.privateDecrypt. Ensure that the private key and encrypted data are handled securely, and consider validating the inputs to prevent potential security issues.Verify that the private key and encrypted session key are securely managed and not exposed in logs or error messages.
packages/nps/gameMessageProcessors/index.ts (1)
17-24: Ensure comprehensive test coverage for types.The
GameSocketCallbackandMessageProcessortypes are defined but not covered by tests. Ensure that these types are used and tested in the codebase to verify their correctness.Verify that these types are used correctly in the codebase and consider adding tests to cover their usage.
packages/nps/gameMessageProcessors/processEncryptedGameCommand.ts (1)
19-113: Ensure secure handling of encryption sessions and messages.The
processEncryptedGameCommandfunction manages encryption sessions and processes messages. Ensure that encryption keys and sensitive data are securely handled and not exposed in logs.Verify that sensitive data is not logged or exposed, and consider adding tests to cover encryption session management.
Tools
GitHub Check: codecov/patch
[warning] 2-113: packages/nps/gameMessageProcessors/processEncryptedGameCommand.ts#L2-L113
Added lines #L2 - L113 were not covered by testspackages/nps/messageStructs/UserStatus.ts (2)
78-91: Verify the correctness offromBytesmethod.Ensure that the
fromBytesmethod correctly interprets the byte data, especially the offsets and sizes used for reading different parts of the buffer.
100-121: Check buffer allocation size intoBytesmethod.Ensure that the buffer size allocated in
toBytesmatches the expected size of serialized data. This prevents potential buffer overflows or data truncation.packages/nps/messageStructs/GameMessage.ts (4)
3-15: EnsureMessageHeaderinitialization logic is correct.The constructor sets the
lengthto a default value if it's zero. Verify that this logic aligns with the intended behavior and doesn't inadvertently override valid zero-length messages.
53-62: Review serialization logic inserializeV1.Ensure that the serialization logic in
serializeV1correctly handles all fields, especially the version and padding. Verify that the buffer size matches the expected structure.
96-124: EnsureSerializableDatahandles data correctly.Verify that
SerializableDatacorrectly manages the buffer size and handles edge cases where data might exceed the allocated buffer.
126-203: CheckGameMessageserialization and deserialization logic.Ensure that
GameMessagecorrectly serializes and deserializes data, especially when handling different versions and message lengths.packages/mcots/payloads/LoginCompleteMessage.ts (1)
134-165: Ensureserializemethod consistency.Verify that the
serializemethod correctly writes all fields to the buffer and that the buffer size matches the expected structure.packages/nps/gameMessageProcessors/processGameLogin.ts (2)
22-32: Ensure secure handling of decrypted data.The
decryptSessionKeyfunction handles sensitive data. Ensure that decrypted data is managed securely, and consider logging only non-sensitive information.
34-100: Verify unpacking logic inunpackUserLoginMessage.Ensure that the logic for unpacking the user login message correctly interprets the serialized data and handles edge cases where data might be malformed.
packages/nps/messageStructs/GameProfile.ts (2)
68-112: VerifyfromBytesmethod logic.Ensure that the
fromBytesmethod correctly interprets the byte data, especially the offsets and sizes used for reading different parts of the buffer.
114-160: EnsuretoBytesmethod consistency.The
toBytesmethod has commented-out sections. Ensure that the serialization logic is complete and consistent with the expected data structure.packages/shared-packets/src/ServerMessage.ts (1)
95-130: LGTM!The
ServerMessagePayloadclass is well-implemented and follows best practices for serialization.
…lation and testing
|
Here's the code health analysis summary for commits Analysis Summary
|
This commit updates the import paths for shared modules in the gateway test file. It replaces the relative import paths with the package name "rusty-motors-shared". This change improves the maintainability and readability of the codebase by using a more explicit and standardized import approach.
This commit updates the import paths for shared modules in the gateway test file. It replaces the relative import paths with the package name "rusty-motors-shared". This change improves the maintainability and readability of the codebase by using a more explicit and standardized import approach.
This commit adds unit tests for the tunables module in the database package. The tests cover the functionality of retrieving tunable values, setting tunable values, and handling invalid tunable names. This addition improves the reliability and maintainability of the codebase by ensuring the correctness of the tunables module. start works, lobby loads
…ackages - start works, lobby loads
This commit updates the validatePersonaName function in the persona package. It adds an enum for response codes and replaces the hard-coded response code with the corresponding enum value. This change improves the readability and maintainability of the code by using descriptive names for response codes. start works, lobby loads, persona is dupe
…rom gateway started, lobby loads, new toon dupe
…nd login packages
This commit refactors the `processGameLogin` function in the `gameMessageProcessors` module. It removes the creation of a new `UserStatus` message and instead updates the existing `userStatus` object with the customer ID, persona ID, and ban information. This change improves the efficiency and readability of the code by eliminating unnecessary object creation. start works, lobby loads, new toon dupe
…ay, lobby, login, and mcots packages states, lobby loads, new toon dupe
…ay, lobby, login, and mcots packages starts, lobby loads, new toon dupe
starts, lobby loads, new toon dupe
The tsconfig.json file in the sessions package has been updated to include the "test" directory in the "include" section. This change ensures that the test files are included in the TypeScript compilation process.
|
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Tests
Chores
.gitignoreto exclude unnecessary files from tracking.