M
Minimum Caterpillar
GitOps
MergePR
and
UpdateReleaseRepo
steps serialize Git operations per connector token using an internal "Git Restraint" lock (limit 1, FIFO) to avoid secondary rate limits on the Git provider. If the lock-holding step's completion event is ever lost, the lock never releases and has no recovery path short of the TTL (6 months). Every subsequent step against that token queues and eventually times out (
MARK_EXPIRED
) with no indication in the step logs of what it's actually waiting on. Today, unblocking requires a support escalation and a manual database fix by Harness engineering.
What we'd like
  1. A self-service way for account/project admins to view and release a stuck Git Restraint lock (API and/or UI action) instead of relying on Harness engineering to clear it from the database.
  2. A "Git Restraint" command unit surfaced in the
    MergePR
    step's execution log, analogous to what
    UpdateReleaseRepo
    already shows, so a queued/blocked step clearly reports that it's waiting on the lock (and ideally which execution holds it) rather than showing no logs at all until it expires.
Why it matters
Right now a stuck lock is invisible to the customer until every Merge PR step using that connector token starts timing out, and the only way out is a support ticket plus a manual backend intervention. Self-service visibility and release would let teams unblock themselves in minutes instead of hours, and would surface the
disableGitRestraint
workaround as an informed choice rather than something support has to explain after the fact.
Example
We hit this on a production account: a Merge PR step's lock-release event was silently dropped during a brief consumer-lag incident, leaving the lock
ACTIVE
for ~17.5 hours. Every Merge PR step across the account using that connector token queued behind it and expired at the 10-minute step timeout with zero log output, until Harness on-call manually deleted the lock document from the database.
Today's workaround (and why it's not enough)
  • disableGitRestraint
    step parameter skips the lock entirely, but that reintroduces the risk of secondary Git provider rate limiting it exists to prevent.
  • The only other option today is filing a support ticket and waiting for Harness engineering to manually clear the lock from the database, which is exactly what extended the incident above to ~17.5 hours.