Task IDs not stable #385
Labels
S-bug
Severity: bug
Comments
hawkw
added a commit
that referenced
this issue
Mar 28, 2023
Tokio Console generates its own sequential Id for internal tracking and indexing of objects (tasks, resources, etc.). However, this Id will be recreated if Console is restarted. In order to provide more useful information to the user, the task Id generated by Tokio can be used in the task list and task details screens instead. If used in this way, the ID field in the task list and task detail views will be stable across restarts of Console (assuming the monitored application is not restarted). This also frees up horizontal space, as the `task.id` attribute doesn't need to be displayed separately. The disadvantage of using Tokio's task Id is that it is not guaranteed to be present by the type system. To avoid problems with missing task Ids, the Tokio task Id is store in addition to the `span::Id` (used to communicate with the `console-subscriber`) and the sequential console `Id` (used in the `store`). If a task is missing the `task.id` field for whatever reason it will still appear, but with an empty ID. If multiple runtimes are active, then duplicate ID values will appear. Fixes: #385 Co-authored-by: Eliza Weisman <[email protected]>
Open
hawkw
added a commit
that referenced
this issue
Sep 29, 2023
Tokio Console generates its own sequential Id for internal tracking and indexing of objects (tasks, resources, etc.). However, this Id will be recreated if Console is restarted. In order to provide more useful information to the user, the task Id generated by Tokio can be used in the task list and task details screens instead. If used in this way, the ID field in the task list and task detail views will be stable across restarts of Console (assuming the monitored application is not restarted). This also frees up horizontal space, as the `task.id` attribute doesn't need to be displayed separately. The disadvantage of using Tokio's task Id is that it is not guaranteed to be present by the type system. To avoid problems with missing task Ids, the Tokio task Id is store in addition to the `span::Id` (used to communicate with the `console-subscriber`) and the sequential console `Id` (used in the `store`). If a task is missing the `task.id` field for whatever reason it will still appear, but with an empty ID. If multiple runtimes are active, then duplicate ID values will appear. Fixes: #385 Co-authored-by: Eliza Weisman <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What crate(s) in this repo are involved in the problem?
tokio-console, console-subscriber
What is the issue?
I have a service which creates two long-running tasks as part of its initialization. They end up with task ids 1 & 2 as expected. The service creates a task per request, and I see those show up as expected.
initial state
after running some requests
However, when I reconnect, I see the task ids have scrambled - the long running tasks no longer have ids 1 & 2 (in this case 2 is preserved, but associated with the other long-running task).
immediately disconnect and reconnect
I'd really like task ids to be stable so that I can use them for reference. Ideally they'd be monotonically increasing in order of task spawns, so they can also be used to understand when things are spawned in relation to each other.
How can the bug be reproduced?
Logs, error output, etc
No response
Versions
Possible solution
No response
Additional context
No response
Would you like to work on fixing this bug?
maybe
The text was updated successfully, but these errors were encountered: