tracing

Requirement - what kind of business use case are you trying to solve?

Actual the windows executables (jaeger-agent.exe, jaeger-collector.exe, ...) don't have a version set. It is hard to identify the current used version and check if the actual used version is outdated.

Probl

Bug description

When the backend API responds with 500 error code then the loader on charts section loads infinitely

Expected behavior

Charts should show No Data like in trace table.

Version information

Is your feature request related to a problem? Please describe.

Useful for networking tracing to convert from network order to host order.

Describe the solution you'd like

int[8|16|32|64] bswap(int[8|16|32|64])

We can make bswap() infer the integer width and return the appropriate integer. Previous discussi

Bug Report

Version

tracing-core v0.1.21
Also current 0.2.0 as documented on tracing.rs

Crates

tracing-core

Description

tracing_core::dispatcher::get_default() (and consequently tracing::dispatcher::get_default()) takes a FnMut argument, which it executes exactly once. The use of FnMut here is unnecessarily restrictive.

Proposal

Change it to tak

It will be useful to have the help specific to use case.

Existing Behavior:
uftrace --help and uftrace replay --help gives the same help prompt.

New Behavior:
uftrace --help can give the help for entire application.
uftrace replay --help can give the help for uftrace replay only.

Reason:

1. This will help narrow down the options available for subprogra

Out of scope during Twitch Series but a nice to have feature that can be implemented

Booking is not currently using Subscription, and it could be done by leveraging parametrized Subscriptions.

Tasks to complete in order to implement this feature:

• Modify onUpdateBooking Subscription to include customer and status
• Implement onUpdateBooking subscription in the Fron

The recently added flags in timescale/promscale#578 are yet to be updated in prom-migrator's readme which can be found here.

It seems to me that UTC is selected for on the wire representation of time as well as in the database (jaegertracing/jaeger#712), which sort of makes sense, at least with a somewhat naive handling of timezones. However, I think that the Jaeger UI should support displaying times in the timezone local to the user, i.e. of the browser as to reduce the mental load when viewing