mirror of
https://github.com/openobserve/openobserve.git
synced 2026-11-04 16:09:05 +00:00
Bhargav
bf27a488d6
`auto_merge_enabled` is one of the two events that start this workflow,
and it fires on the same click that enqueues the PR. GitHub freezes a
queued PR's branch, so by the time the run finishes translating, the
push it exists to make is rejected with GH006.
The push loop then made the failure much harder to read than it needed
to be. It was written for one failure mode -- losing a race to a
concurrent push -- so it treated every rejection as a lost race and
rebased. GH006 is a policy rejection, not a race: the rebase is a no-op
("Current branch ... is up to date") and the next two attempts fail
identically, burying the real reason under a log that looks like
flakiness.
- Classify the rejection at push time. GH006 / merge-queue /
protected-branch stops on the FIRST attempt with an error naming the
cause and the fix (dequeue, re-run, re-queue). Non-fast-forward keeps
the existing rebase retry.
- Check for queue membership in the guard, before any API spend. When
the PR is already queued the run cannot land a commit, so translating
would spend the DeepSeek budget building one with nowhere to go.
verify-translations.yml still gates the queue, so a genuinely
untranslated PR is still blocked from main.
Fail-open on the queue lookup: a transient API error falls through to
"not queued" so a blip can never silently stop translations from being
generated. The push-time check backstops it.
No keys are lost in either path -- .translation_state.json still lists
them as pending, so the next run picks them up.