Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Fix 500 Error After Setting Authorized IP #7334

Merged
merged 1 commit into from
Dec 11, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion backend/middleware/ip_limit.go
Original file line number Diff line number Diff line change
Expand Up @@ -35,7 +35,7 @@ func WhiteAllow() gin.HandlerFunc {
}
}
code := LoadErrCode()
helper.ErrWithHtml(c, code, "ip_limit")
helper.ErrWithHtml(c, code, "err_ip_limit")
}
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The provided code change replaces "ip_limit" with "err_ip_limit" in an error handling function named WhiteAllow. The change does not introduce any obvious irregularities or significant performance issues, unless there was a specific context that requires such wording changes. It simply updates one of the strings used to identify or describe errors within the application.

If this is part of a larger project where consistency and possibly internationalization (i18n) considerations are at play, ensuring that all error messages align across resources might be advisable. However, for now, it seems the update addresses internal naming conventions rather than impacting functionality directly.

Recommendations: While the change itself doesn't require immediate attention, maintaining consistent error message names can improve readability and maintainability, especially if i18n practices are followed in future modifications.

Expand Down
2 changes: 1 addition & 1 deletion frontend/src/views/app-store/installed/detail/index.vue
Original file line number Diff line number Diff line change
Expand Up @@ -259,7 +259,7 @@ const get = async () => {
}
paramModel.value.memoryLimit = res.data.memoryLimit;
paramModel.value.cpuQuota = res.data.cpuQuota;
paramModel.value.memoryUnit = res.data.memoryUnit !== '' ? res.data.memoryUnit : 'MB';
paramModel.value.memoryUnit = res.data.memoryUnit !== '' ? res.data.memoryUnit : 'M';
paramModel.value.allowPort = res.data.allowPort;
paramModel.value.containerName = res.data.containerName;
paramModel.value.advanced = false;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes between lines 259 in both versions of the code indicate an inconsistency in handling memory units. The original code assigns "M" to paramModel.value.memoryUnit if res.data.memoryUnit is an empty string. However, the version with the comment has a typo, assigning 'MB' rather than 'M'. It would be advisable to correct this discrepancy to ensure consistent behavior with whatever logic expects regarding memory unit formatting. Here's how you can adjust it:

Original Code snippet (line 259):

-         paramModel.value.memoryUnit = res.data.memoryUnit !== '' ? res.data.memoryUnit : 'MB';
+         paramModel.value.memoryUnit = ... // Ensure consistent unit format

Corrected Version:

         paramModel.value.memoryUnit = res.data.memoryUnit !== '' ? res.data.memoryUnit : 'M'; 
         // Optionally, consider adding a function that formats memory units based on your requirements
         paramModel.value.memoryUnit = validateMemoryUnit(res.data.memoryUnit);
     ```
Remember to implement a corresponding validation function (`validateMemoryUnit`) if necessary to handle more complex scenarios where different input values might denote the same measurement unit.

Expand Down
Loading