mirror of
https://github.com/nushell/nushell.git
synced 2025-04-23 20:58:19 +02:00
122bcff356
8 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Piepmatz
|
66bc0542e0
|
Refactor I/O Errors (#14927)
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx
you can also mention related issues, PRs or discussions!
-->
# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.
Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
As mentioned in #10698, we have too many `ShellError` variants, with
some even overlapping in meaning. This PR simplifies and improves I/O
error handling by restructuring `ShellError` related to I/O issues.
Previously, `ShellError::IOError` only contained a message string,
making it convenient but overly generic. It was widely used without
providing spans (#4323).
This PR introduces a new `ShellError::Io` variant that consolidates
multiple I/O-related errors (except for `ShellError::NetworkFailure`,
which remains distinct for now). The new `ShellError::Io` variant
replaces the following:
- `FileNotFound`
- `FileNotFoundCustom`
- `IOInterrupted`
- `IOError`
- `IOErrorSpanned`
- `NotADirectory`
- `DirectoryNotFound`
- `MoveNotPossible`
- `CreateNotPossible`
- `ChangeAccessTimeNotPossible`
- `ChangeModifiedTimeNotPossible`
- `RemoveNotPossible`
- `ReadingFile`
## The `IoError`
`IoError` includes the following fields:
1. **`kind`**: Extends `std::io::ErrorKind` to specify the type of I/O
error without needing new `ShellError` variants. This aligns with the
approach used in `std::io::Error`. This adds a second dimension to error
reporting by combining the `kind` field with `ShellError` variants,
making it easier to describe errors in more detail. As proposed by
@kubouch in [#design-discussion on
Discord](https://discord.com/channels/601130461678272522/615329862395101194/1323699197165178930),
this helps reduce the number of `ShellError` variants. In the error
report, the `kind` field is displayed as the "source" of the error,
e.g., "I/O error," followed by the specific kind of I/O error.
2. **`span`**: A non-optional field to encourage providing spans for
better error reporting (#4323).
3. **`path`**: Optional `PathBuf` to give context about the file or
directory involved in the error (#7695). If provided, it’s shown as a
help entry in error reports.
4. **`additional_context`**: Allows adding custom messages when the
span, kind, and path are insufficient. This is rendered in the error
report at the labeled span.
5. **`location`**: Sometimes, I/O errors occur in the engine itself and
are not caused directly by user input. In such cases, if we don’t have a
span and must set it to `Span::unknown()`, we need another way to
reference the error. For this, the `location` field uses the new
`Location` struct, which records the Rust file and line number where the
error occurred. This ensures that we at least know the Rust code
location that failed, helping with debugging. To make this work, a new
`location!` macro was added, which retrieves `file!`, `line!`, and
`column!` values accurately. If `Location::new` is used directly, it
issues a warning to remind developers to use the macro instead, ensuring
consistent and correct usage.
### Constructor Behavior
`IoError` provides five constructor methods:
- `new` and `new_with_additional_context`: Used for errors caused by
user input and require a valid (non-unknown) span to ensure precise
error reporting.
- `new_internal` and `new_internal_with_path`: Used for internal errors
where a span is not available. These methods require additional context
and the `Location` struct to pinpoint the source of the error in the
engine code.
- `factory`: Returns a closure that maps an `std::io::Error` to an
`IoError`. This is useful for handling multiple I/O errors that share
the same span and path, streamlining error handling in such cases.
## New Report Look
This is simulation how the I/O errors look like (the `open crates` is
simulated to show how internal errors are referenced now):
## `Span::test_data()`
To enable better testing, `Span::test_data()` now returns a value
distinct from `Span::unknown()`. Both `Span::test_data()` and
`Span::unknown()` refer to invalid source code, but having a separate
value for test data helps identify issues during testing while keeping
spans unique.
## Cursed Sneaky Error Transfers
I removed the conversions between `std::io::Error` and `ShellError` as
they often removed important information and were used too broadly to
handle I/O errors. This also removed the problematic implementation
found here:
|
||
|
Piepmatz
|
02fc844e40
|
Fix commands::network::http::*::*_timeout tests on non-english system (#14640)
<!-- if this PR closes one or more issues, you can automatically link the PR with them by using one of the [*linking keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g. - this PR should close #xxxx - fixes #xxxx you can also mention related issues, PRs or discussions! --> # Description <!-- Thank you for improving Nushell. Please, check our [contributing guide](../CONTRIBUTING.md) and talk to the core team before making major changes. Description of your pull request goes here. **Provide examples and/or screenshots** if your changes affect the user experience. --> I had issues with the following tests: - `commands::network::http::delete::http_delete_timeout` - `commands::network::http::get::http_get_timeout` - `commands::network::http::options::http_options_timeout` - `commands::network::http::patch::http_patch_timeout` - `commands::network::http::post::http_post_timeout` - `commands::network::http::put::http_put_timeout` I checked what the actual issue was and my problem was that the tested string `"did not properly respond after a period of time"` wasn't in the actual error. This happened because my german Windows would return a german error message which obviosly did not include that string. To fix that I replaced the string check with the os error code that is also part of the error message which should be language agnostic. (I hope.) # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> None. # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` \o/ # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. --> |
||
Alex Kattathra Johnson
|
cda9ae1e42
|
Shorten --max-time in tests and use a more stable error check (#14494)
- fixes flakey tests from solving #14241 # Description This is a preliminary fix for the flaky tests and also shortened the `--max-time` in the tests. # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> --------- Signed-off-by: Alex Kattathra Johnson <alex.kattathra.johnson@gmail.com> |
||
Alex Kattathra Johnson
|
22ca5a6b8d
|
Add tests to test the --max-age arg in http commands (#14245)
- fixes #14241 Signed-off-by: Alex Johnson <alex.kattathra.johnson@gmail.com> |
||
Jack Wright
|
0d060aeae8
|
Use pipeline data for http post|put|patch|delete commands. (#13254)
# Description Provides the ability to use http commands as part of a pipeline. Additionally, this pull requests extends the pipeline metadata to add a content_type field. The content_type metadata field allows commands such as `to json` to set the metadata in the pipeline allowing the http commands to use it when making requests. This pull request also introduces the ability to directly stream http requests from streaming pipelines. One other small change is that Content-Type will always be set if it is passed in to the http commands, either indirectly or throw the content type flag. Previously it was not preserved with requests that were not of type json or form data. # User-Facing Changes * `http post`, `http put`, `http patch`, `http delete` can be used as part of a pipeline * `to text`, `to json`, `from json` all set the content_type metadata field and the http commands will utilize them when making requests. |
||
Kira
|
a86a7e6c29
|
Allow http commands' automatic redirect-following to be disabled (#11329)
Intends to close #8920 This PR suggests a new flag for the `http` commands, `--redirect-mode`, which enables users to choose between different redirect handling modes. The current behaviour of letting ureq silently follow redirects remains the default, but two new options are introduced here, following the lead of [JavaScript's `fetch` API](https://developer.mozilla.org/en-US/docs/Web/API/fetch#redirect): "manual", where any 3xx response to a request is simply returned as the command's result, and "error", where any 3xx response causes a network error like those caused by 4xx and 5xx responses. This PR is a draft. Tests have not been added or run, the flag is currently only implemented for the `http get` command, and design tweaks are likely to be appropriate. Most notably, it's not obvious to me whether a single flag which can take one of three values is the nicest solution here. We might instead consider two binary flags (like `--no-following-redirects` and `--disallow-redirects`, although I'm bad at naming things so I need help with that anyway), or completely drop the "error" option if it's not deemed useful enough. (I personally think it has some merit, especially since 4xx and 5xx responses are already treated as errors by default; So this would allow users to treat only immediate 2xx responses as success) # User-facing changes New options for the `http [method]` commands. Behaviour remains unchanged when the command line flag introduced here is not used.  |
||
Filip Andersson
|
f6ca62384e
|
changes Reqwest to Ureq. (#8320)
# Description _(Thank you for improving Nushell. Please, check our [contributing guide](../CONTRIBUTING.md) and talk to the core team before making major changes.)_ This pull request removes `Reqwest` and replaces it with `Ureq` to remove some of our dependencies, giving us faster compile times as well as smaller binaries. `Ureq` does not have an async runtime included so we do not need build heavy dependencies such as `Tokio`. From older tests I had the number of build units be reduced from `430 -> 392`. The default of `Ureq` uses `Rustls` but it has been configured to instead use `native_tls` which should work exactly the same as the `tls` works now. I removed `content-length` from the http commands as after refactoring i did not see a reason to have it available, correct me if this is something we should preserve. In the medium, to long term, we should maybe consider changing to `rustls` to have the same `tls` on all platforms. # User-Facing Changes _(List of all changes that impact the user experience here. This helps us keep track of breaking changes.)_ # Tests + Formatting Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass # After Submitting If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. |
||
Jérémy Audiger
|
c1d76bfac7
|
Add unit tests for HTTP commands. (#8267)
# Description Following the comment from @fdncred: https://github.com/nushell/nushell/pull/8144#issuecomment-1442514338. I added some unit tests for HTTP commands. The tests are not exhaustive, but at least, this is a first good step IMO. # User-Facing Changes None. # Tests + Formatting Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass # After Submitting If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. |