stage → production: sync-to-zesty conflict-recovery patch + 9 self-healed ZUID mappings - #101
Merged
Merged
Conversation
Per ardeay (2026-09-09): PR #97's stage-merge sync-to-zesty run failed on Aug 31 with 401 (token expired), so view records were never created in Zesty for these 4 pages. Token was rotated today; a fresh stage push that touches these 4 files puts them in DIFF_BASE scope, so sync-to-zesty will POST-create view records + capture ZUIDs into zesty.config.json. Trivial HTML comment at line 1 is the diff signal (valid HTML5 - comments before DOCTYPE are explicitly allowed by spec, standards mode preserved). Affects: - culture-cares.html - duda-vs-content-one.html - nonprofit-website-rfp-template.html - webflow-vs-content-one.html
Trigger sync-to-zesty view auto-create for 4 pending pages
…xisting ZUID Per ardeay (2026-09-09): before this patch, any file present on disk but without a ZUID mapping in zesty.config.json triggers a POST /web/views on stage sync. If the Zesty instance already has a view record with that fileName (usually because it was created manually in the editor before its ZUID made it into config), the POST fails with 400 'filename already exists' and the whole sync crashes. Every subsequent file in newFiles is never touched. The patch teaches createNew() to recover from that specific 400: catch it, GET /web/<endpoint>, find the record whose fileName matches, and continue as if we had just created it. The workflow's writeback step then commits the resolved ZUID into zesty.config.json so subsequent runs treat it as a normal already-mapped resource. Also: - apiRequest now attaches .status and .bodyText onto the thrown Error so callers can introspect (previously only a string message was available) - apiRequest no longer sends body='null' on GET/DELETE (JSON.stringify(null) = 'null', which some fetch implementations flag) - Small test file exercises the shape of the patch — asserts the recovery branch, the helper function, and the body-on-GET guard all exist. Zero runtime cost since it's opt-in (node scripts/sync-to-zesty.test.js)
…ing-view sync-to-zesty: recover from 'filename already exists' on POST
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
1 participant
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.
Per ardeay (2026-09-09 Discord): "yes self heal then go stage to prod."
What's in this promotion
From #100 (already merged to stage today)
sync-to-zesty.js patched to recover from 400 "filename already exists" on POST by GET-looking up the existing ZUID. Any other error still fails loud.
From the FULL_SYNC dispatch on stage just now (run 34399911849)
The patch immediately self-healed 9 orphaned view records — files that had been on disk but missing ZUID mappings in `zesty.config.json` because someone created their view records manually in the Zesty editor earlier in the year without the ZUID ever making it back to git. Now mapped:
From #99 earlier today
The 4 pages that kicked off the whole thread: culture-cares, duda-vs-content-one, nonprofit-website-rfp-template, webflow-vs-content-one — already live on prod via manual publish. This promotion carries their content forward from stage git so it stays in sync.
Left unmapped (deliberately skipped by the sync script — not a bug)
Both are extensionless views. The script correctly can't infer whether they're templateset or pageset from the filename alone. If those need mapping, someone creates them in the Zesty admin (choosing templateset for a parent URL view, pageset for a per-instance view) then adds their ZUID to `zesty.config.json` by hand — same as with any other manually-created templateset.
After merge
Nothing user-visible changes on live URLs — the 4 pages ardeay published earlier stay live at the same URLs; the 9 self-healed ones were already resolving fine, they just weren't sync-managed.