Closed RealOrangeOne closed 6 months ago
Attention: Patch coverage is 94.59459%
with 2 lines
in your changes are missing coverage. Please review.
Project coverage is 71.20%. Comparing base (
db971e6
) to head (0f83176
).
Files | Patch % | Lines |
---|---|---|
src/main.rs | 0.00% | 2 Missing :warning: |
:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
@orhun it seems that you have to approve the CI for the 2 PRs.
But what I could ascertain from a quick look at the code is that prior to this PR errors were handled gracefully. After this PR rustypaste will panic. Not sure I like this.
Yup, I also think that we should handle errors.
There's only 1 panic this introduces, and it's during server startup. Sure, I could facade it to convert a path issue to IoResult
, and let Rust deal with returning that one, or I can call expect
. The latter felt fine for a quick change.
What about the occurrences of PasteType::Url.get_path(&config.server.upload_path).unwrap()
?
Isn't it true that these can panic?
P.S.: but I also noticed the change from fs::create_dir_all(paste_type.get_path(&server_config.upload_path))?
to use an expect, which is probably what you meant in your previous comment.
There are other uses of unwrap
, but those are strictly in tests, which I've not considered to be an issue. If a test panics, it's functionally the same as a failure, which is what we want.
Yes, the fs::create_dir_all
is the only new place the application could panic.
but those are strictly in tests
Oops, once again the gh diff failed me again. all the test headers were not in the code, thus I didn't see that those were tests. All good then.
Yes, the
fs::create_dir_all
is the only new place the application could panic.
I would rather see an error message than a panic. But it's up to orhun.
Yes, it would be better to print out an error message than panicking. Also, there are some lints about the usage of unwrap
in tests 🙂 we can simply replace them with expect
.
Looks like there is a test failure:
---- util::tests::test_safe_join_path stdout ----
thread 'util::tests::test_safe_join_path' panicked at src/util.rs:211:9:
assertion failed: safe_path_join("/foo", "/foobar").is_ok()
stack backtrace:
Description
Check that a joined path is still a child of the original path.
Motivation and Context
When joining paths, there's little protection against directory traversal. From testing, Actix seems to nicely sanitises these in the request, which is great, but it's still better to add a little protection.
How Has This Been Tested?
Unit tests have been added, which pass.
Changelog Entry
Types of Changes
Checklist: