Thank you for the extra context links.

A thought on secondary audit events is that many can be implemented on the persistence layer itself. So every change to the db will automatically drop these logs.

You bring up even more points of "secondary events" such as failed jobs. This would give the provisioner a way to drop an audit logs as a failed event relating to the primary user action.

This does bring up a question though. Should the provisioner log show in the UI as it's own row? Or underneath theCreate Workspac audit log row in some toggle?

I like the idea of toggling because I actually think it might keep the UI simpler. What I would like to avoid is having to put in a bunch of filtering so users can make sense of the view - as@spikecurtis mentioned below, most filtering is probably going to be done in Splunk. IDK though - warrants more thought.

It does seem like we might have to store therequest_id or whatever ID is linking the audit logs in the db somewhere.

Originally I was thinking it can all go on thectx, but@Kira-Pilot brings up examples where that is not the case.

I mean, we should already be storing it on the Audit Logs, but in the case that a request writes something to the database which then gets picked up by some background process (e.g. builds) then yes, the job that gets picked up would need the request ID.

I do like the idea ofrequest_id since it allows linking audit logs to other things too.

I still think there is value inprimary andsecondary, not just for a UI purpose. Theprimary action should be something a user can do in the product and makes intuitive sense.secondary audit logs should be granular and might only make sense to a more technical user.

Have we done any investigation into how other products that often involve linked, async requests handle their audit logs (e.g. CI vendors (e.g. circleci), git providers (e.g. gitlab), or identify-based access tools (e.g. teleport)?

I'm personally curious if there are any patterns in how they link/relate logs, mostly to ensure that we don't do something bespoke that may be confusing for customers who are used to consuming logs from these other platforms (via the UI, consuming via the API, or ingesting into Splunk/StackDriver)

@bpmct I have not, but this is essentially tracing which is rather normal. The onlyflair is how we present it on our UI