Description
This is something I stumbled upon while working on this PR (worth reading for context): getsentry/sentry#88539
Only, when both frontend and backend are involved in an issue, the client OS (e.g. macOS or Windows) is added as client_os. In case the client OS is the only one involved in the issue, it is added as os (client-only issues). In the case of JavaScript, only issues from Meta-Frameworks like Next.js (which have a client and a server) include both OS's.
Problem
If users have multiple JS projects which are client-only (e.g. React) and Meta-Frameworks, the data is technically wrong when they want to filter by tags for the OS. When filtering for just os you would get a mix of client and server OS. When you filter for client_os, you would get only the issues from the Meta-Framework, and not the React-only issues.
Issue with client- and server-side
Tags: ["client_os", "Windows \u003E=10"] and ["os.name", "Linux"]
Context: os with backend OS and client_os with client OS
Issue with only client-side (only JS)
Tags: ["os.name", "Mac OS X"] (no "client_os")
Context: os with client OS (no client_os)
Proposed Solution
It would be breaking to just change all client-based os to client_os. For example for people who only have a React project which always shows the client OS as os and never as client_os - so there was never a reason to filter for client_os.
But we could add the additional client_os tag for all frontend issues to be consistent here. So, when someone searches for client_os, you not only get the issue from Next.js, but also from client-side libraries like React.
In a follow-up (which would be breaking - but it's technically also a fix), this could be unified to never include the client OS in os but always as client_os.