MR: Pending <!-- The first line of the MR must be one of the following: 1. `MR: Pending` 2. `MR: <MR link with trailing +>`, and the first description line of the MR should be `Issue: <Issue link with trailing +>` 3. `MR: No MR` For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/index.html#1-to-1-relationship-of-issues-to-mrs --> <!-- The following sections should be filled out as part of the refinement process before the issue is prioritized. For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#2-pre-iteration-planning-meeting --> **NOTE: This issue should be considered ~blocked until all work in the https://gitlab.com/groups/gitlab-org/-/epics/10461+ is completed. Only then can we do a complete review of the final logging statements for compliance and security. For now, a preliminary review has been done and there are no concerns. Therefore, moving this to https://gitlab.com/groups/gitlab-org/-/epics/11041+ as it should not be a blocker for GA** ## Description `As a developer or admin supporting the Remote Development feature, I want adequate logging of backtraces and exception messages so that we are able to debug problems that happen both in SaaS and for on-prem installations, but without leaking sensitve information into logs.` Related MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119559+ Notes from @cwoolley-gitlab (see [internal slack thread](https://gitlab.slack.com/archives/C03KE0L9NC9/p1683088105098279)): > My main concern is around how the logging of backtraces and exception messages. > > On one hand, there’s docs that ask us to avoid this in order to avoid leaking sensitive information into the logs (even though there’s existing places I found in the codebase that do it anyway). > > But on the other hand, this is important information in order for us to be able to debug problems that happen both in SaaS and for on-prem installations. > > I’m not sure how we are supposed to reconcile these concerns. There’s some helpers around structured logging and such, but I haven’t had time to dig into them. See original issues for more context: - https://gitlab.com/gitlab-org/gitlab/-/issues/408783+ - https://gitlab.com/gitlab-org/gitlab/-/issues/409066+ ## Acceptance Criteria ## Tasks - [ ] Review all the structured logging added as part of https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119146+ for compliance to standards and security (e.g. not leaking sensitive info in exceptions or backtraces). See TODOs added in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119559+ for context. ## Technical Requirements TODO: Fill out or delete [If applicable, please list out any technical requirements for this feature/enhancement.] ## Design Requirements TODO: Fill out or delete [If applicable, please provide a link to the design specifications for this feature/enhancement.] ## Impact Assessment TODO: Fill out or delete [Please describe the impact this feature/enhancement will have on the user experience and/or the product as a whole.] ## User Story TODO: Fill out or delete [Provide a user story to illustrate the use case for this feature/enhancement. Include examples to help communicate the intended functionality.] <!-- Replace with other type, e.g. bug or maintenance, if appropriate --> <!-- Replace with other subtype if appropriate --> <!-- By default, all issues start in the unprioritized status. See https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#-remote-development-planning-process --> <!-- For simplicity and to avoid triage bot warnings about missing workflow labels, we will default to issues starting at the refinement phase -->