potential bug: commits intermittently marked as detached

TL;DR
We are running a shipit instance wrapped around the shipit-engine gem v0.38.0. Starting on April 7, 2025, we have seen that commits are intermittently being marked as detached and as a result, not display on Shipit UI as an undeployed commit. I was wondering if the shipit-engine team has seen anything like this as well?

Details

• I still haven't been able to figure out why these are being marked as detached. From what I've seen in shipit-engine code, there are a few ways that a commit will be marked as detached:
  • During GithubSyncJob, if there is a shared parent commit identified, then the children are marked as detached
    • I've used the Github REST API for commits to query the parent.sha on the detached commits' parents and children and haven't found any commits that share a parent.
  • If it is a Pull Request, then the head and base sha are marked as detached
    • The commits being marked as detached are commits merged to the master branch and not a pull request. All of our commits have NULL entries for pull_request_number merge_request_id
• Our shipit instance wraps around shipit-engine gem v0.38.0
  • I don't see anything in the latest shipit-engine version v0.39.0 that would fix this: https://github.com/Shopify/shipit-engine/releases/tag/v0.39.0, plus v0.39.0 was released in Jan 2024 whereas we started seeing commits marked as detached in the database in April 2025
• Only single commits (not 2+ in a row) are being marked as detached
• No obvious pattern in timing for when they are marked as detached
• Nothing has changed with our Github merge strategy - we use Squash and Merge
• Not seeing any force pushes on the commit or on commits before it or after
• Didn't find anything in Github change log that would cause this issue: https://github.blog/changelog/
• This problem is not limited to a single stack - it is happening on multiple stacks that point to different repositories
• In one example, different commits are being marked as detached for 2 stacks (staging and production) that point to the same repository and branch

Any help or insight would be appreciated! I can provide more details too, if needed.

Start with app/jobs/shipit/github_sync_job.rb and the detached-commit logic in app/models/shipit/merge_request.rb. Trace how GitHub commit parents and pull-request metadata are read for the reported single-commit cases, comparing that data with the database records. Done means identifying the detached-marking path and confirming a reproducible cause or a focused fix.