Suspect commit not working as expected

[Alena86]

Self-Hosted Version

self-hosted version 26.1.0 but 25.1.0 as well.

CPU Architecture

x86_64

Docker Version

28.3.3, build 980b856

Docker Compose Version

v2.39.2-desktop.1

Machine Specification

• My system meets the minimum system requirements of Sentry

Installation Type

Fresh install of 26.1.0 self-hosted

Steps to Reproduce

1. I have installed basic self-hosted setup from this repo by checking out the tag 26.1.0
2. One modification is that I added haproxy in front of the web, added LDAP integration, as well as changed the URL to be my internal URL so that Sentry can be setup with GitHub Enterprise setup.
3. It spins up fine. I create a project in Sentry, and GitHub Entperprise integration.
4. In the integration, I add repository and Code mapping for the project. Repository is a Python language code.
5. Have my teammates log in to create the users in Sentry, and use User mapping to map them in Sentry to the users in GitHub which we know it works good.
6. Make sure that CODEOWNERS file is set with 3 people in it (person making code changes would be 2nd or 3rd) and make sure we import it in the code mapping as well as make sure that project is set to assign the issue to suspect commit)
7. Create script that is capturing exception to Sentry, and commit that into the repo.
8. Once the repo is setup with some code, we push that to the main branch and create release and assign commits to it by running these 2 sentry-cli commands:

• sentry-cli.exe releases new -p <sentry_project> "<release_matching_version_from_python_package/repo>"
• sentry-cli.exe releases set-commits --auto "<release_from_previous_command>"

9. Releases are showing in Sentry UI, and the commits are also showing in UI when I look at the release that was just created.

10. When the script is triggered, that captures different kind of Errors/Exceptions to Sentry, we can see events getting created in the Issues Feed but the assignment is not done properly.

11. For the Stack Trace Root, I have tried using the full path where I'm running the script, as well as modifying the abs_path in the function called in before_send.

12. Tried even adding the parameter include_source_context=True to sentry initialization and even that didn't help.

I do know that code mapping needs to be setup properly in order for suspect commit to work. I tried with many different mapping and still not getting the right results. Out of 50 tests, maybe 2 assign it properly to suspect commit, 10 would assign it to the 1st person in CODEOWNERS file, and the rest would not assign the issue to anyone.
In every test, whenever the code mapping is changing, the code was also changed to have a new type of issue, to make sure there was noone assign to that issue type before testing.

Questions I have:

1. Am I the only person having issues with getting suspect commit feature to work properly? First common sense question LOL
2. For the Stack Trace Root, is it possible to setup to be anything in front of the name of the pacakge? Like if the absolute path for stack trace is C:\Users\myusername\Documents\pythonPackage1.2.3\pythonFile.py we were setting Stack Trace Root to be "C:\Users\myusername\Documents\pythonPackage1.2.3" or once we modify the abs path to be app:///pythonPackage1.2.3/pythonFile.py we would set Stack Trace Root to be app:///. Is there a way to set in code mapping to accept anything in front of the name of the project?
3. What part of Sentry setup/containers, is in charge of setting this suspect commit?
4. Whenever we create the release with sentry-cli commands, is it actually creating the connection to GitHub about that, or is it generating like a separate tracking of that in backing database like Postgres??

This would be it for now.
Any help with this would help as I've been working on these for a while and cannot get consistent behavior with it.

Thank you!

Expected Result

We would expect to see the event and have Suspect Commit pointing to the last person that made the changes to the file that is showing in the stacktrace.
Having the project setting to auto assign the issue to suspect commit, we would also expect to have AssignedTo field to be filled with person that is set as suspect commit.

Actual Result

A lot of times, we don't get the Suspect commit showing at all even though the code mapping was set proper.
Sometimes the assigning would set up to 1st person in the CODEOWNERS file.
And out of 50 times maybe 2 times it did assign to the proper person. When trying to reproduce the same steps/settings that worked to another error/release, it didn't work.

The only error in logs would be the warning:
[WARNING] django.request: Not Found: /api/0/projects/sentry/test_python/events/e7fae1db41144023a8321531cf08ffc9/committers/ (status_code=404 request=<WSGIRequest: GET '/api/0/projects/sentry/test_python/events/e7fae1db41144023a8321531cf08ffc9/committers/'>)
Which started happening recently, and it wasn't there when we started testing this feature and trying to make it work. So not sure how related it is, but it wasn't there at the beginning when feature didn't work.

Event ID

No response