Conversation
Third fix, same root cause each time: I verified in an environment that was not
the one it runs in.
GitHub runs the step as `bash -e {0}`. Combined with `set -o pipefail` that
means any non-zero anywhere kills the script at that line with NO output — a red
run and an empty log, which is the least debuggable possible failure. It hit
twice: the Actions-API 403, then `grep` returning 1 because a commit touched no
mirrored paths. grep exiting 1 on no-match is a normal answer, not an error, and
it was the very first loop iteration — so the last run produced literally
nothing between the env block and `exit 1`.
`set +e` explicitly. Every branch here decides for itself and reports why; `-e`
adds nothing but the ability to die mid-check without saying so.
Also filter LIVE/TIP/EXPECTED through a 40-hex check. On failure `gh` prints its
error body to stdout, which was landing in those vars and being compared as if
it were a sha; now a broken call resolves to empty and trips the labelled
DEGRADED branch instead.
Verified by extracting the step and running it under `bash -e` against the real
APIs, both paths: healthy -> "production content is current", exit 0, silent;
broken token -> one WATCHDOG DEGRADED line, exit 1. That is the check I should
have been running from the first commit.
fix(watchdog): stop the script dying silently under bash -e
The end-to-end test found the real defect. merge-on-green did everything right for #2547 — content-only diff, ci-success 2/2 green — then failed at the last step: Merging #2547 — diff is exactly src/content, ci-success green (2/2) merge failed for #2547 (already merged, or bypass unavailable) Being an OrganizationAdmin does not make `gh pr merge` bypass "Protect Prod". gh enforces the branch policy and requires an explicit `--admin`. I hit this exact error merging #2544 by hand an hour earlier, added the flag, and did not carry it back into the workflow. `--admin` also waives the required status check, so note what it is not waiving: this job has already established for itself that the diff is exactly `src/content` and that every ci-success run on the commit is green. The gate is enforced in code above; --admin only drops the human review, which is the entire purpose of this workflow. A merge we decided to make and then failed to make now fails the run loudly instead of logging a warning and going green. That warning is why the pipeline looked healthy for 40 minutes while Konrad's content sat unpublished — the exact silent failure this work exists to remove. Two more from the same class, found by running the step under `bash -e`: `set +e` with explicit checks, because -e kills the loop mid-flight with no output; and numeric validation of TOTAL/GREEN/PRS, because gh prints its JSON error body to stdout and the loop was iterating over the words of an error message as if they were PR numbers. Verified under `bash -e`: bogus SHA -> "not green (-1/0)", exit 0; real commit with no candidate PR -> "No open content-publish candidates", exit 0.
fix(automerge): pass --admin, and stop swallowing a failed merge
…53d925) Bumps src/content on production (main) from c268e5d → 153d925 (peanut-content latest = mono@f4a21dc). Single-file submodule pointer change. Publishes content already merged + mirrored from mono that the dev-targeted auto-PRs never promote to main.
…202607281706 content: publish latest to production (src/content → peanut-content@153d925)
…0728-185158 content: publish latest to production (src/content → peanut-content@6ad0006)
PR #2505 switched history ENS resolution to GET /ens/reverse/:address, but its backend dependency (peanut-api-ts#1237) was never merged or deployed — prod returns 404, so activity history silently fell back to raw addresses for every user. Reverting restores the working JustaName client-side lookup on web. Re-land #2505 once #1237 is live in prod. This reverts commit d5e9789.
This reverts commit aa16a83.
…lable the server-first hook shipped in #2505 before its backend endpoint (peanut-api-ts#1237) deployed, so prod 404s every lookup and history shows raw addresses. instead of reverting, keep server-first (needed for native, where the mainnet RPC blocks WebView origins via CORS) and engage JustaName's client-side lookup only when the server call fails. web gets ENS names back immediately; native picks up the server path automatically once #1237 deploys, with no frontend re-land. non-OK now throws instead of caching a negative result for 24h.
… call coderabbit: the previous waitFor only observed the fetch being fired, so the undefined assertion could pass before the query resolved. wait for the post-resolve re-render and assert the client fallback stays disabled when the server answers authoritatively.
Contributor
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
Code-analysis diffPainscore total: 6655.8 → 6657.76 (+1.96) 🆕 New findings (2)
✅ Resolved (3)
📈 Painscore deltas (top movers)
|
Contributor
🧪 UI test report — ✅ all greenSuites
📊 Coverage (unit)
⏱ 10 slowest test cases
|
…-side-2505 fix(history): restore ENS names via client-side fallback while /ens/reverse is undeployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Back-merge of everything on
mainbut not yet ondev— 8 commits:Why this PR is
main → devdirectly instead of the usualchore/backmerge-*branch: the content-bot commit 5008b3e onmainis unsigned, and the "All branches" ruleset (required signatures, no bypass actors) rejects any push/API-merge that introduces it to a new branch — a signed local merge was rejected too (GH013 flags the unsigned ancestor, not the merge commit). Merging this PR creates a GitHub-signed merge commit ondev, the same path those commits took intomain(#2561). If the rule complains at merge time, merge withgh pr merge --admin.Zero conflicts (verified via a local test merge). No manual edits.
🤖 Generated with Claude Code