feat: improve the time precision of observations

[pokliu]

Describe the bug

The set_power method is not actually the last one executed. The second-to-last OpenAI-Generation is the last one executed.`

To reproduce

The execution time of set_power is very short, and even displayed as 0.00s on the Langfuse UI. The display order of the timeline may be disordered.

SDK and container versions

python langfuse SDK version: 2.57.7 Langfuse local deployment version: 3.7.1

Additional information

Is it because the time precision is relatively low that langfuse cannot sort the reported data correctly? Maybe nanoseconds should be used, or event time should not be used as the sorting basis.

Are you interested to contribute a fix for this bug?

No

[dosubot[bot]]

Hey @pokliu! I'm here to help you with any bugs, questions, or contributions you have regarding Langfuse. I can assist you while waiting for a human maintainer. Let's tackle this issue together!

The issue you're experiencing with the timeline sorting in Langfuse might be related to how events are sorted based on their timestamps. The sortBatch function in the Langfuse codebase sorts events by their timestamp in ascending order, placing update events last ^[1]. If the timestamps are too close together, especially with very short execution times like 0.00s, this could lead to incorrect ordering in the display.

Currently, the sorting logic does not explicitly handle sub-second precision beyond what is provided by the timestamp. If higher precision is needed, such as nanoseconds, this would require changes to how timestamps are recorded and sorted.

To address this, you might consider suggesting an enhancement to the Langfuse team to increase the time precision used for sorting, or to implement additional logic to handle events with identical timestamps.

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other}

[maxdeichmann]

@pokliu thanks for sharing this. As you run this on the local machine, could you share some additional data with us? Could you go to the network tab and share the returned data for the following endpoint with us (please redact any sensitive data):

If you do not want to share a screenshot, can you confirm that the startTime property is exactly the same for the two elements you are looking at? You should find them in the "observations" list in the response body.

[pokliu]

Hi @maxdeichmann .

Since the elements in the observations field in the network are not sorted by timeline, I converted observations to global variables by right-clicking the mouse, and extracted the startTime in each element through map function.

You can see that there are two identical startTime: "2025-01-15T09:00:57.928Z"

[maxdeichmann]

Hi @maxdeichmann .

Since the elements in the observations field in the network are not sorted by timeline, I converted observations to global variables by right-clicking the mouse, and extracted the startTime in each element through map function.

You can see that there are two identical startTime: "2025-01-15T09:00:57.928Z"

@pokliu thanks a lot for checking this out. As the two observations have exactly the same timestamp, they might be in the wrong order. We will look into improvements here down the line and improve the time precision of our spans. This is currently a limitation of the Javascript Date object. We will need to add high resolution timestamps for our JS SDK as well as for our server implementation.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale. Please reopen if the issue persists.