-
Notifications
You must be signed in to change notification settings - Fork 2k
Moving session recording file ops behind an interface #53702
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Moving session recording file ops behind an interface #53702
Conversation
lib/events/filesessions/fileops.go
Outdated
| return trace.Wrap(err) | ||
| } | ||
|
|
||
| if err := f.Truncate(n); err != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if any of these operation fails, should we keep the file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably not. The caller of WritePart() removes the file in case of a failure and there's no reason to hang onto the reserved file if we bail out because of a failed truncation.
The individual part files should probably be removed too, but we don't currently remove them on failure (at least not near the callsite) and I don't really want to change effective behavior with this PR
lib/events/filesessions/fileops.go
Outdated
|
|
||
| func loggingClose(ctx context.Context, closer io.Closer, log *slog.Logger, msg string, args ...any) { | ||
| if err := closer.Close(); err != nil { | ||
| log.ErrorContext(ctx, msg, append(args, "error", err)...) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there anything that we can do to avoid the allocation here? Perhaps maybe the caller should annotate the logger with any desired args via log.With before calling this function? Alternatively if this is only used in a handful of places, perhaps we could get rid of this function and just call close in line?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah handling the close inline isn't really annoying enough to warrant the helper. Even when the encrypted version is added, that's only like 3 more spots we'll have to do the check. I opted to remove it for now, but preloading the logger is probably the best way to do something like this going forward, so I'll try to keep that in mind for later 👍
b23ae13 to
5c9233c
Compare
1a1949e to
476ebc1
Compare
This PR prepares session recording to use different file operations based on configuration (e.g. encrypted or not). There shouldn't be any functional changes to how recordings are saved included in this PR