Persist traces

[franzliedke]

For debugging purposes, it is useful to retain traces (e.g. those linked in a ticket in a bug tracker) for longer than the default retention period.

To do so, some form of bookmarking feature is necessary that would:

• create a copy of all spans and related failures in a dedicated (separate?) database table,
• creates a new link where this persistent data is available (separate URL so that the default trace view does not have to check for traces against two possible data sources)
• the /t/<id> route could actually check against both data sources...

@jgraichen What do you think? Any other difficulties I have overlooked?

[franzliedke]

What's the current behavior of the bookmark / star button, by the way?

[franzliedke]

@jgraichen When you have the time, please provide details about your preferred implementation, so that interested people 😁 could take care of it without running in the wrong direction.

[jgraichen]

I've always thought about having additional tables for traces and spans that are saved. When hitting the save button, the trace, child traces, and all relevant spans are copied into the new tables. I'd not have made a separate endpoint to access saved traces but would always lookup in the regular table and, if there is no match, look in the saved traces table.