On the vulnerability details page, changing the state does not show the author

Summary

On the vulnerability details page, changing the state in the header shows "Confirmed just now by", but does not show the author:

Peek_2023-02-01_01-54

Note that this only occurs when the details page is first loaded with a vulnerability that's in the "Needs triage" state. If the vulnerability is in another state on page load, then the bug won't occur. However, there's a related issue if the vulnerability is in another state: if user B changed the state previously and user A then changes the state, the header will show the new status, but as updated by user B instead of user A:

2023-02-02_01-45-12

Steps to reproduce

1. Go to the vulnerability details page for a vulnerability in the "Needs triage" state.
2. Change the state from "Needs triage" to one of the other ones.
3. Verify that the "<state> just now by" text is shown in the header, but with no author.

Example Project

https://gitlab.com/gitlab-examples/security/security-reports

Possible fixes

This bug was introduced when we switched from the REST API to GraphQL mutations for state changes. The source of the bug is that we're watching for changes to vulnerability.state to update the header, and the vulnerability is changed twice: once from the mutation, which doesn't have the user ID, and once from the vulnerability refetch, which does have the user ID. The mutation triggers first and changes the vuln state, but there's no user ID, so the header is updated with no user. The refetch triggers second with a user ID, but because the vuln state doesn't change, the watcher isn't triggered and the header isn't updated:

1

2023-02-02_01-30-56

We can look into one of several possible fixes:

1. Assume that the current user (using gon.current_user_id) is the one that did the state change. This is the quick fix that should work fine, but isn't particularly robust, because we're assuming something.

2. Add the author data to the mutation response. This would be the ideal so that we don't have to refetch the vulnerability, but it requires backend work.

3. Rework the GraphQL mutation to use refetchQueries to refetch the vulnerability, and also do optimistic update so that the UI is updated immediately.

Verification steps

From Needs triage to other status

1. go to this vulnerability
2. check that status of vulnerability is "Needs triage"
3. change the status to any status you want
4. verify that the header shows "[Confirmed|Dismissed|Resolved] by <your name>" (without the need to refresh the page like before)

Change status on vulnerability with status set by someone else

1. go to this vulnerability
2. check that status is "Confirmed"
3. change the status to "Resolved" or "Dismissed"
4. verify that the header shows "[Dismissed|Resolved] by <your name>" (without the need to refresh the page like before)