[pull] main from tokio-rs:main #41
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
hawkw
force-pushed
the
main
branch
4 times, most recently
from
802ee42 to
c3a7660
Compare
…hannel (#238) ## Motivation Currently, there are some rather bad issues that occur when the event buffer is at capacity and events are dropped. Completely *losing* data due to buffer capacity is relatively okay: if we set a bound on how much memory the console can use, and we don't record new things that occur when we've reached that limit, this is correct and acceptable behavior. However, the current design can result in *incorrect* data when events are lost due to the buffer being at capacity. This is because we currently record things like starting to poll a task/resource, ending a poll, dropping a task/resource/async op, and waker operations, as individual events in the buffer. This means that we can have a situation where the creation of a task was recorded, because there was buffer capacity at the time, but then when the task ended, the buffer was full, so we never recorded its termination. That results in the tasks appearing to run forever and never terminate --- see issue #230. Similarly, if we record the beginning of a poll, but drop the end-of-poll event because we're at capacity, this means we will (incorrectly) record a poll that goes on forever, which is obviously incorrect. I think this may also be the cause of the false positives with the lost waker lint (#149), if we record a waker drop but missed a waker clone that previously occurred. The change in #212 fixed one category of issue that occurs due to event buffer capacity --- when a task, resource, or async op's _creation_ event is dropped due to buffer capacity, we skip any subsequent events related to that task/resource/op. However, this doesn't fix issues where the subsequent events are the ones that are dropped. ## Solution This branch proposes a solution to this whole category of event buffer capacity related issues. Unfortunately, this requires rewriting a *lot* of `console-subscriber`'s internals. In the new approach, we now _only_ send events over the channel when creating a new task, resource, or async op. Those events now contain an `Arc` holding the stats for that entity. Another clone of the `Arc` is stored in the `tracing_subscriber::Registry`'s [span extensions] for the span corresponding to that entity. When the `ConsoleLayer` records subsequent events for a particular entity, such as starting/ending a poll, it looks up the span by ID, and updates the stats type stored in its extensions. The aggregator stores its clone of the `Arc` in a map of entities, just like it does currently, but no longer handles actually updating the stats; just building wire format updates from any tracked entities whose data was updated by the layer. This should fix all issues where dropping something due to event buffer capacity results in incorrect data. Once we have successfully recorded the *creation* of a task, resource, or async op, any subsequent updates to its stats are *guaranteed* to be reliable. If the channel is at capacity and we fail to record a new resource/task/op, we never create a stats extension for it, and we won't record anything for it at all. Otherwise, it will always have correct data recorded. When possible, the stats in the `Arc`ed stats are updated atomically. In some cases, this isn't easily possible, and some fields of the stats types are stored in a mutex. In particualr, this is required for storing timestamps. I don't really love that, but these mutices should be contented very infrequently. Stats aren't marked as having unset updates until after the stats inside the mutices have been updated, so the aggregator will not try to lock the mutex if the layer is currently updating it; instead, it will simply be included in the next update once the layer is no longer touching it. Mutices here will only be contended when multiple threads are updating a task's stats at the same time, which should occur very rarely...and in most cases, they *still* won't have to contend a mutex, since access to most of the mutices are guarded by an atomic variable for e.g. determining which thread actually was the last to complete a concurrent poll. The biggest performance downside of the mutices is probably not actually contention, but the additional heap allocation required when using `std::sync::Mutex`. However, since we have conditional `parking_lot` support, parking_lot can be used to avoid requiring additional allocations. In the future, it's probably possible to make more of this atomic by converting timestamps into integers and storing them in atomic variables. I haven't done this yet because both the protobuf timestamps and `std::time` timestamps are larger than a single 64-bit number and it might take a little extra work to ensure we can nicely fit them in an `AtomicUsize`...but we can probably do that later. [span extensions]: https://docs.rs/tracing-subscriber/latest/tracing_subscriber/registry/struct.SpanRef.html#method.extensions Signed-off-by: Eliza Weisman <[email protected]>
<a name="0.1.1"></a> ## 0.1.1 (2022-01-18) #### Bug Fixes * only send *new* tasks/resources/etc over the event channel (#238) ([fdc77e2](fdc77e2)) * increased default event buffer capacity (#235) ([0cf0aee](0cf0aee)) * use saturating arithmetic for attribute updates (#234) ([fe82e17](fe82e17)) #### Changes * moved ID rewriting from `console-subscriber` to the client (#244) ([095b1ef](095b1ef))
<a name=""></a> ## (2022-01-18) #### Features * feature-flag `tracing-journald` dependency (#250) ([24f25db](24f25db)) * add vi style keybinds for tables (#223) ([1845c99](1845c99)) #### Bug Fixes * fix task lookup in async ops view (#257) ([9a50b63](9a50b63)) * don't make details requests with rewritten IDs (#251) ([4ec26a8](4ec26a8)) * fix build error with journald enabled ([a931b7e](a931b7e)) * increase default event buffer capacity a bit (#235) ([0cf0aee](0cf0aee)) * wrap controls line when the terminal is too narrow (#231) ([ef41507](ef41507)) * don't enable crossterm mouse capture (#222) ([e020d66](e020d66), closes [#167](167))
Currently, the `tokio-console` CLI's crate is named `tokio-console`, but the directory is just named `console`. This causes some problems: for example, when we publish a release, the release tags are named `tokio-console-vX.Y.Z`. The GitHub Action for automatically publishing changelogs to GitHub Releases looks for the changelog in `<tag-prefix>/CHANGELOG.md`, but this doesn't work, because the tag prefix is not the name of the directory. So, the automatic release publishing currently fails for the console crate: https://github.com/tokio-rs/console/runs/4860467681?check_suite_focus=true I figured the easiest solution was just to rename the directory to match the crate name --- this is more consistent anyway.
Task `Details` are tracked by the remote's `span::Id` while the `Task::id()` is the friendly id. The comparison in the view is changed to use the remote span ids and the field in `Details` is renamed to match. Fixes: #262
The `tracing_core::metadata::Kind` type was not intended to be matched exhaustively, so that its internal representation could be changed without causing a breaking change. However, some fairly recent compiler changes broke this, and made the type exhaustively matched. This resulted in `tracing-core` 0.1.22 breaking `console-api`. This PR fixes the breakage by changing `console-api` to avoid exhaustively matching on `Kind`s. Fixes #270
This should ensure we don't see any compilation errors. Signed-off-by: Eliza Weisman <[email protected]>
…272) I don't think it's accurate that a compiler change made this exhaustively matchable when it wasn't before. All versions of rustc since 1.0.0 have allowed exhaustively matching on that kind of data structure from outside of the defining crate.
This PR moves `console-api/proto/google/protobuf/timestamp/timestamp.proto` to `console-api/proto/google/protobuf/timestamp.proto` to match the directory structure in https://github.com/protocolbuffers/protobuf. This may not be important for generating code for Rust, however other languages such as Javascript need the path to match the official definitions in order to work with the official [google-protobuf](https://www.npmjs.com/package/google-protobuf) library.
) ## Motivation Currently, the `console-subscriber` crate does not compile on targets without 64-bit atomic operations, such as `mipsel-unknown-linux-musl`. This is because a 64-bit atomic is used to store the last task ID that polled a resource. ## Solution This branch changes this code to use the `AtomicCell` type from `crossbeam-utils`, instead. `AtomicCell` will use atomic operations on targets that support 64-bit atomics, and fall back to using a mutex on platforms that don't have 64-bit atomic operations. This should fix the build on those platforms. Fixes #279
The `tokio-console` crate's `homepage` URL was incorrect after the crate was moved from a directory named `console` to one named `tokio-console`, which results in a 404 error when following the "homepage" link on crates.io. This commit fixes that. Fixes #280
Documentation about setting the default subscriber in tracing and the builder interface for console-subscriber moved, resulting in a few broken links. Updates those links to their current locations.
…287) ## Motivation Currently, if compiled in debug mode, the `console-subscriber` crate's `PollStats::end_poll` function will panic if a poll duration is negative (i.e. if the poll's end timestamp occurred before its start timestamp). Because the console currently uses non-monotonic `SystemTime`s rather than monotonic `Instant`s (due to serialization requirements), this means we are potentially succeptible to clock skew adjustments. If one occurs during a poll, and the system clock goes backwards, we may panic here. This isn't great! ## Solution This branch fixes the panic by removing the assertions, and changing `end_poll` to simply bail and print a warning rather than panicking when encountering a negative poll duration. This is a short-term solution; a better long-term solution would be to change `console-subscriber` to use monotonic `Instant`s rather than non-monotonic `SystemTime`s (as discussed [here][1] and [here][2]). Fixes #286 [1]:#254 [2]: #286 (comment)
## Motivation Currently, the `console-subscriber` crate records all timestamps as `SystemTime`s. This is because they are eventually sent over the wire as protobuf `Timestamp`s, which can be constructed from a `SystemTime`. They cannot be constructed from `Instant`s, because `Instant` is opaque, and does not expose access to the underlying OS time. However, using `SystemTime` is not really correct for our use case. We only use timestamps for calculating durations; we only have to serialize them because some durations are calculated in the console UI rather than in-process. We *don't* need timestamps that are globally consistent with a shared timebase, but we *do* need monotonicity --- using `SystemTime` leaves us vulnerable to clock skew, if (for example), an NTP clock skew adjustment causes the system clock to run backwards far enough that a poll appears to end "before" it started (as in issue #286). If we were using monotonic `Instant`s, all polls should always have positive durations, but with `SystemTime`s, this isn't necessarily the case. Furthermore, `Instant::now()` may have less performance overhead than `SystemTime::now()`, at least on some platforms. ## Solution This branch changes `console-subscriber` to always take timestamps using `Instant::now()` rather than using `SystemTime::now()`, and store all timestamps as `Instant`s. In order to convert these `Instant`s into `SystemTime`s that can be sent over the wire, we construct a reference `TimeAnchor`, consisting of a paired `Instant` and `SystemTime` recorded at the same time when the `ConsoleLayer` is constructed. We can then construct "system times" that are monotonic, by calculating the duration between a given `Instant` and the anchor `Instant`, and adding that duration to the anchor `SystemTime`. These are not *real* system timestamps, as they will never run backwards if the system clock is adjusted; they are relative only to the base process start time as recorded by the anchor. However, they *are* monotonic, and all durations calculated from them will be reasonable. This is part of the change I proposed in #254. I'm not going to close that issue yet, though, as it also described potentially switching to use the `quanta` crate rather than `std::time::Instant` to reduce the overhead of recording monotonic timestamps. Fixes #286
This branch refactors how the aggregator task builds update messages. In particular, it factors out the shared code between building the initial update for a subscription and building the subsequent updates in `publish` into methods that are called with an `Include` enum to determine whether the update should include all tasks/resources/ops, or just the ones since the last update. This makes the code in `add_instrument_subscription` and in `publish` much easier to read. This is just the refactor part from #289 split out into a separate branch; this should make no functional change. If we decide that #289 is the correct way to fix the bug, we can rebase that branch onto this, so that it _just_ includes the bugfix. This way, we can land the refactor anyway, because I think it's nice.
* refac(subscriber): factor out update construction This branch refactors how the aggregator task builds update messages. In particular, it factors out the shared code between building the initial update for a subscription and building the subsequent updates in `publish` into methods that are called with an `Include` enum to determine whether the update should include all tasks/resources/ops, or just the ones since the last update. This makes the code in `add_instrument_subscription` and in `publish` much easier to read. This is just the refactor part from #289 split out into a separate branch; this should make no functional change. If we decide that #289 is the correct way to fix the bug, we can rebase that branch onto this, so that it _just_ includes the bugfix. This way, we can land the refactor anyway, because I think it's nice. * fix(subscriber): record timestamps for updates last ## Motivation Currently, when constructing an update message to send over the wire, a timestamp is taken first, and then the protobuf data is constructed. This can lead to issues where the "now" timestamp is actually _before_ timestamps present in the stats sent in that update, since the stats for a particular task/resource/async op might be updated on another thread after taking the update's "now" timestamp. This results in issues like #266. ## Solution There's no actual reason to take those timestamps *before* we assemble the update. This branch changes the aggregator to build all the various data updates in an update message, and *then* record the update's "now" timestamp. Any timestamps for tasks/resources/async ops that are recorded after the update's "now" timestamp will now be included in the *next* update. Fixes #266 Depends on #288
I ran into an issue where putting my .cargo/config.toml with the tokio_unstable rustflag in the sub-project of my workspace where I needed to use tokio-console led to full rebuilds on every cargo build invocation. This was caused by rust-analyzer invoking its cargo commands in the workspace root independent of the directory where the editor (e.g. nvim) is launched from. This led to rust-analyzer not to use the cargo config, while my manual cargo build invocations did use the config, hence requiring full rebuilds on every run. This documentation informs new users of this pitfall. If this documentation is found to be a little on the long side, I can try to move part of this warning into the cargo documentation, which I'm linking to anyways.
Add a new builder method to `console_subscriber::Builder` to configure the filter environment variable to use for `tracing` events. Closes #206 Co-authored-by: Eliza Weisman <[email protected]>
This branch adds documentation to the `console-subscriber` _and_ `tokio-console` READMEs and RustDoc explaining the minimum Tokio versions required by the console. Since instrumentation for different aspects of the runtime has been added over time, this isn't as simple as "the console requires version x.y.z or later"; instead, we provide a list of which console features require which Tokio versions. The console should be capable of at least limited operation with any Tokio version >= 1.0, but some data will not be available (such as wakers, resource >instrumentation, etc). Closes #281
#### Features * add `Builder::filter_env_var` builder parameter (#276) ([dbdb149](dbdb149), closes [#206](206)) #### Bug Fixes * record timestamps for updates last (#289) ([703f1aa](703f1aa), closes [#266](266)) * use monotonic `Instant`s for all timestamps (#288) ([abc0830](abc0830), closes [#286](286)) * bail rather than panic when encountering clock skew (#287) ([24db8c6](24db8c6), closes [#286](286)) * fix compilation on targets without 64-bit atomics (#282) ([5590fdb](5590fdb), closes [#279](279))
In the past we have marked commits which update tonic as `chore`, which excludes them from the release notes. However, when we update tonic to a new (pre-1.0) major version, such as from 0.10 to 0.11, this is a breaking change for both the `console-api` and the `console-subscriber` crates. As such, it shouldn't be skipped. This change adds a new commit type `update`, to use for updating dependencies. It will have it's own section in the release notes. A commit preprocessing rule has been added to the Git-Cliff config file to change commit subjects from `chore: bump tonic` to `update: bump tonic` so that they're caught in the new category (this will fix it for the next release which includes upgrading tonic from 0.10 to 0.11). The contributor guide has also been updated to mention this new commit type.
There is a new version of `cargo-dist` available, 15.1. This change updates Cargo.toml and the release CI job to the latest version. This is in preparation for releasing a new version of the console crates.
…scriber-v0.3.0 (#557) ## 🤖 New release * `tokio-console`: 0.1.10 -> 0.1.11 * `console-api`: 0.6.0 -> 0.7.0 * `console-subscriber`: 0.2.0 -> 0.3.0 ## `tokio-console` ## tokio-console-v0.1.11 - (2024-06-10) ### Added - Replace target column with kind column in tasks view ([#478](#478)) ([903d9fa](903d9fa)) - Add flags and configurations for warnings ([#493](#493)) ([174883f](174883f)) - Add `--allow` flag ([#513](#513)) ([8da7037](8da7037)) ### Documented - Add note about running on Windows ([#510](#510)) ([a0d20fd](a0d20fd)) ### Fixed - Ignore key release events ([#468](#468)) ([715713a](715713a)) - Accept only `file://`, `http://`, `https://` URI ([#486](#486)) ([031bddd](031bddd)) - Fix column sorting in resources tab ([#491](#491)) ([96c65bd](96c65bd)) - Only trigger lints on async tasks ([#517](#517)) ([4593222](4593222)) - Remove duplicate controls from async ops view ([#519](#519)) ([f28ba4a](f28ba4a)) - Add pretty format for 'last woken' time ([#529](#529)) ([ea11ad8](ea11ad8)) ## `console-api` ## console-api-v0.7.0 - (2024-06-10) ### <a id = "0.7.0-breaking"></a>Breaking Changes - **Bump tonic to 0.11 ([#547](#547 ([ef6816c](https://github.com/tokio-rs/console/commit/ef6816caa0fe84171105b513425506f25d3082af))<br />This is a breaking change for users of `console-api` and `console-subscriber`, as it changes the public `tonic` dependency to a semver-incompatible version. This breaks compatibility with `tonic` 0.10.x. ### Documented - Fix typo in proto ([#472](#472)) ([2dd3559](2dd3559)) ### Updated - [**breaking**](#0.7.0-breaking) Bump tonic to 0.11 ([#547](#547)) ([ef6816c](ef6816c)) ## `console-subscriber` ## console-subscriber-v0.3.0 - (2024-06-10) ### <a id = "0.3.0-breaking"></a>Breaking Changes - **Bump tonic to 0.11 ([#547](#547 ([ef6816c](https://github.com/tokio-rs/console/commit/ef6816caa0fe84171105b513425506f25d3082af))<br />This is a breaking change for users of `console-api` and `console-subscriber`, as it changes the public `tonic` dependency to a semver-incompatible version. This breaks compatibility with `tonic` 0.10.x. ### Added - Replace target column with kind column in tasks view ([#478](#478)) ([903d9fa](903d9fa)) - Reduce retention period to fit in max message size ([#503](#503)) ([bd3dd71](bd3dd71)) - Support grpc-web and add `grpc-web` feature ([#498](#498)) ([4150253](4150253)) ### Documented - Add a grpc-web app example ([#526](#526)) ([4af30f2](4af30f2)) - Fix typo in doc comment ([#543](#543)) ([ff22678](ff22678)) ### Fixed - Don't save poll_ops if no-one is receiving them ([#501](#501)) ([1656c79](1656c79)) - Ignore metadata that is not a span or event ([#554](#554)) ([852a977](852a977)) ### Updated - [**breaking**](#0.3.0-breaking) Bump tonic to 0.11 ([#547](#547)) ([ef6816c](ef6816c))
tokio-console would be 0.1.11.
Bumps [braces](https://github.com/micromatch/braces) from 3.0.2 to 3.0.3. - [Changelog](https://github.com/micromatch/braces/blob/master/CHANGELOG.md) - [Commits](micromatch/braces@3.0.2...3.0.3) --- updated-dependencies: - dependency-name: braces dependency-type: indirect ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
We need to make truncate_registry_path can handle Windows path as well. Because tokio-console can connect to any server from different platforms, so we use the same path separator to have the same experience.
) When the recorded process spawns a lot of tasks and execute a lot of operations, a red message can be seen on the top of the console saying `dropped: 14319181 async_ops, 1601630 tasks, 634586 resources`. That means that the buffer is not sufficiently big to record these and someone in the tokio Discord advised to use the `TOKIO_CONSOLE_BUFFER_CAPACITY` variable to tune that buffer. Turns out it was not a thing, so this pr adds it.
Use the `dep:` syntax to explicitly define `parking_lot` as dependency in the feature definition, added in Rust 1.60. This allows to avoid the rename of `parking_lot` to `parking_lot_crate` internally.
Update all dependencies on `tonic` and `tonic-build` to v0.12, along with the related `prost`, `prost-types` and `prost-build` crates to v0.13.1. BREAKING CHANGE: This is a breaking change for users of `console-api` and `console-subscriber`, as it changes the public `tonic`, `prost` and `prost-types` dependency to a semver-incompatible version. This breaks compatibility with `tonic` 0.11.x as well as `prost`/`prost-types` 0.12.x. Co-authored-by: Hayden Stainsby <[email protected]>
The MSRV of 1.64 is long gone and now 1.74. Therefore, the `trycmd` dev-dependency can be unpinned and bumped to the latest version.
We should check the length before using the index to access it. Closes #565 Test locally: https://github.com/tokio-rs/console/assets/29879298/5c4fd5da-e1c7-490b-bd67-1257972076d3 But it is difficult to view it, you can try it by following the steps from the issue.
…#578) A number of new or updated Clippy lints in Rust 1.80.0 need to be fixed. An update to the `dead_code` pointed out that the `AggregatorHandle` is not used, and it is not constructable from outside the crate because it has a private field. This struct was introduced in #451 as part of the `Server::into_parts` method. Originally, this method was going to return the `AggregatorHandle`, which wrapped the join handle from the task where the `Aggregator` had been spawned. This was later replaced by returning the `Aggregator` itself, which the user had the obligation to spawn themselves. However, it seems that the `AggregatorHandle` wasn't removed, even though it was never used. A new lint is the one for unexpected `--cfg` items. We now need to declare those in `Cargo.toml`. An update to `needless_borrows_for_generic_args` causes a false positive changing a `&mut` to a move, which we can't do as the same value is used afterwards.
…onsole-v0.1.12 (#576) ## 🤖 New release * `tokio-console`: 0.1.11 -> 0.1.12 * `console-api`: 0.7.0 -> 0.8.0 * `console-subscriber`: 0.3.0 -> 0.4.0 ## `tokio-console` ## 0.1.12 - (2024-07-29) ### Fixed - Handle Windows path correctly ([#555](#555)) ([6ad0def](6ad0def)) - Avoid crash when accessing selected item ([#570](#570)) ([9205e15](9205e15)) ### Updated - Upgrade tonic to 0.12 ([#571](#571)) ([5f6faa2](5f6faa2)) ## `console-api` ## 0.8.0 - (2024-07-29) ### <a id = "0.8.0-breaking"></a>Breaking Changes - **Upgrade tonic to 0.12 ([#571](#571 ([5f6faa2](5f6faa2)) This is a breaking change for users of `console-api` and `console-subscriber`, as it changes the public `tonic`, `prost` and `prost-types` dependency to a semver-incompatible version. This breaks compatibility with `tonic` 0.11.x as well as `prost`/`prost-types` 0.12.x. ### Updated - [**breaking**](#0.8.0-breaking) Upgrade tonic to 0.12 ([#571](#571)) ([5f6faa2](5f6faa2)) ## `console-subscriber` ## 0.4.0 - (2024-07-29) ### <a id = "0.4.0-breaking"></a>Breaking Changes - **Upgrade tonic to 0.12 ([#571](#571 ([5f6faa2](5f6faa2)) This is a breaking change for users of `console-api` and `console-subscriber`, as it changes the public `tonic`, `prost` and `prost-types` dependency to a semver-incompatible version. This breaks compatibility with `tonic` 0.11.x as well as `prost`/`prost-types` 0.12.x. ### Added - Add `TOKIO_CONSOLE_BUFFER_CAPACITY` env variable ([#568](#568)) ([a6cf14b](a6cf14b)) ### Fixed - Remove unused `AggregatorHandle` and fix other lints ([#578](#578)) ([c442063](c442063)) ### Updated - [**breaking**](#0.4.0-breaking) Upgrade tonic to 0.12 ([#571](#571)) ([5f6faa2](5f6faa2)) Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
I know the best solution is to ensure we can distinguish singular or plural here. But for now, let's correct the grammar issue first.
…#585) Bumps [rollup](https://github.com/rollup/rollup) from 4.12.0 to 4.22.4. - [Release notes](https://github.com/rollup/rollup/releases) - [Changelog](https://github.com/rollup/rollup/blob/master/CHANGELOG.md) - [Commits](rollup/rollup@v4.12.0...v4.22.4) --- updated-dependencies: - dependency-name: rollup dependency-type: indirect ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…/examples/grpc_web/app (#586) Bumps [vite](https://github.com/vitejs/vite/tree/HEAD/packages/vite) from 5.1.7 to 5.4.8. - [Release notes](https://github.com/vitejs/vite/releases) - [Changelog](https://github.com/vitejs/vite/blob/v5.4.8/packages/vite/CHANGELOG.md) - [Commits](https://github.com/vitejs/vite/commits/v5.4.8/packages/vite) --- updated-dependencies: - dependency-name: vite dependency-type: direct:development ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [tonic](https://github.com/hyperium/tonic) from 0.12.0 to 0.12.3. - [Release notes](https://github.com/hyperium/tonic/releases) - [Changelog](https://github.com/hyperium/tonic/blob/master/CHANGELOG.md) - [Commits](hyperium/tonic@v0.12.0...v0.12.3) --- updated-dependencies: - dependency-name: tonic dependency-type: direct:production ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
In Tokio, the futures for tasks are stored on the stack unless they are explicitly boxed. Having very large futures can be problematic as it can cause a stack overflow. This change makes use of new instrumentation in Tokio (tokio-rs/tokio#6881) which includes the size of the future which drives a task. The size isn't given its own column (we're running out of horizontal space) and appears in the additional fields column. In the case that a future was auto-boxed by Tokio, the original size of the task will also be provided. Two new lints have been added for large futures. The first will detect auto-boxed futures and warn about them. The second will detect futures which are large (over 1024 bytes by default), but have not been auto-boxed by the runtime. Since the new lints depend on the new instrumentation in Tokio, they will only trigger if the instrumented application is running using `tokio` 1.41.0 or later. The version is as yet, unreleased. Both lints have been added to the default list. Co-authored-by: Eliza Weisman <[email protected]>
For users who build tokio-console by installing it with `cargo`, it is common to use the `--locked` flag to indicate that the dependency versions from the lock file should be used. So it's worth having those dependencies up to date. This change checks in the result of running `cargo update` without changing the manifest (`Cargo.toml`) files. The patch (pre-1.0 minor) version change to `tonic-build` included a deprecation (rename) and some clippy lint allow directives in the generated Rust files. The update to `tracing` in the lockfile from 0.1.37 to 0.1.40 includes the changes from tokio-rs/tracing#2562. This change causes an instrumented future to be entered one final time when the future is dropped, so that any code run in the drop implementation will be in the scope of the span. This causes the number of polls recorded for a task to be incremented by 1 right before it is dropped. Due to this change, some of the `console-subscriber` tests needed to be updated. This behaviour was already present for many application using the `console-subscriber`, but not yet in the tests because we hadn't updated the lockfile for a while.
The screenshots on the docs.rs page for tokio-console are a bit out of date. They are from v0.1.8 and still show the Target column instead of the Kind column. With the task size instrumentation and new lints which will be released in the next version of Tokio Console, we need screenshots which match what the user will see. The same goes for the screenshots in the repository root README.md, which anyone visiting the repo page on GitHub will see. This change adds new screenshots for docs.rs and replaces the README screenshots. We have to keep the docs.rs images from previous versions still, since docs.rs pages for previous versions still reference them. Additionally, a new CI job to build the docs.rs documentation and also to check that all the images referenced from the tokio-console README file (which is used on docs.rs) are present in the repository, as we can't inspect the documentation until the change is merged. This is done via a new `xtask` operation.
…onsole-v0.1.13 (#581) ## 🤖 New release * `tokio-console`: 0.1.12 -> 0.1.13 (✓ API compatible changes) * `console-api`: 0.8.0 -> 0.8.1 (✓ API compatible changes) * `console-subscriber`: 0.4.0 -> 0.4.1 (✓ API compatible changes) ## Changelog ## `tokio-console` ## 0.1.13 - (2024-10-24) ### Added - Add large future lints ([#587](#587)) ([ae17230](ae17230)) ### Fixed - Correct the grammar issue ([#579](#579)) ([f8e1bee](f8e1bee)) ## `console-api` ## 0.8.1 - (2024-10-24) _No outward facing changes_ ## `console-subscriber` ## 0.4.1 - (2024-10-24) ### Added - Add large future lints ([#587](#587)) ([ae17230](ae17230)) Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Change the minimum version of tonic from 0.12 to 0.12.3. This fixes compilation in downstream projects with old lock files, since the generated code now uses a constant only present in tonic 0.12.3. Closes #592
This pull request introduces a new stream API named "WatchState." Currently, it only provides the current temporality, which will enable clients to check if the server has been paused.
As reported in issue #592, in our release of `console-api` 0.8.1, we specified that we required a tonic version of 0.12 in teh Cargo.toml file. However, since we had generated Rust code with `tonic-build` 0.12.3, we had some code that was only present in `tonic` from 0.12.3 as well. This error was fixed in #593. However, this showed a gap in our CI testing, we don't test against minimum versions of our dependencies to catch this kind of error. This change adds a CI job to check the minimal versions of our direct dependencies. We perform a cargo update with the `-Z direct-minimal-versions` flag and then perform cargo check. This would have caught the previous error and will catch any new ones of a similar type. One downside to this approach is that we must explicitly give a minimum version for our direct dependencies that is equal to or greater than the minimum version that any of of transitive dependencies specify for that same crate. However this check is probably worth the annoyance.
See: https://github.com/tokio-rs/console/actions/runs/12277528296/job/34257115867?pr=602 I used `cargo clippy --workspace --all-targets --no-deps --fx` to fix it. Signed-off-by: Rustin170506 <[email protected]>
close #601 As Remedy said, because we are not directly dependent on `idna`. So we just need to bump the `url` to 2.5.4 or later. Signed-off-by: Rustin170506 <[email protected]>
…/app (#610) Bumps [vite](https://github.com/vitejs/vite/tree/HEAD/packages/vite) from 5.4.8 to 5.4.14. - [Release notes](https://github.com/vitejs/vite/releases) - [Changelog](https://github.com/vitejs/vite/blob/v5.4.14/packages/vite/CHANGELOG.md) - [Commits](https://github.com/vitejs/vite/commits/v5.4.14/packages/vite) --- updated-dependencies: - dependency-name: vite dependency-type: direct:development ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )