Repository navigation
fix(org): finish interrupted verifications and compare drafts by markup - #167
Conversation
Text alone missed an unpublished image, link or formatting change, and a Textile div block cut the comparison short. A section one page leaves out counts as empty.
Saving and publishing are decided apart, from the draft and the live page, so a run that saved but failed to publish is completed by the next. The draft is compared again right before publishing and put back if another edit arrived. Requests for one org, and for the bio, run one at a time, so a remove cannot overtake a slow write. A token the extension did not place is reported, not skipped.
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 40 minutes. View limit detailsLimit details: You’ve used the included review currently available. Review configuration: ⚙️ Run configuration
📒 Files selected for processing (6)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| await saveOrgDraft(rsiToken, sid, ORG_VERIFICATION_FIELD, draft); | ||
| } | ||
| return failed(409, "Unpublished changes"); |
There was a problem hiding this comment.
🔴 Failed rollback leaves token queued
When the second check finds another edit and saveOrgDraft refuses rollback, verifyOrg still returns 409. The token remains in the draft and can go live with a later edit.
Learn more
After saving a verification token, the second preview comparison can detect a pending edit. The conflict branch then tries to restore the previous history. RSI can return HTTP 200 with success: 0, which reportsSuccess treats as failure elsewhere; this branch ignores the response. A failed restore leaves the token in the draft, yet the response reports only an unpublished-changes conflict.
Example: A token save succeeds, another officer edits the manifesto, and the restore request returns { success: 0, msg: "ErrCsrf" }. The request returns 409 while history still contains the token, ready to be included in a future publication.
Recommended fix: Inspect rollback's HTTP status and body with reportsSuccess, and return a rollback failure that exposes the unresolved draft state. Avoid claiming restoration when the compensating write fails.
Was this helpful? React with 👍 or 👎 to provide feedback.
…ken by its own section Putting the draft back after a late conflict re-reads the history first and restores it only while it still holds exactly what this request saved; a refused restore is reported, with the token marked as possibly left in the draft. Whether the token is live is read from the history section alone: a token in another section is one the extension never wrote, so a removal refuses it instead of publishing and reporting success. The re-check before publishing no longer fetches the admin form.
1 participant
Fixes from a review of #165 (org verification), for fleetyards/fleetyards#5465.
What changed
saveDraftworked andpublishDraftfailed, every retry found the token in the draft and did nothing. The token stayed unpublished, and went live with the next officer edit.div.blocks no longer cut a section short.409.409on remove instead of200 changed: false, so the site warns that it's still public. Whether the token is live is read from the history section alone.lib/tokens.ts) instead of the org flow borrowing the bio's.Test plan
pnpm test(95): markup changes, nested divs, missing sections, publish-only retry, re-check with the draft put back, a hand-placed token, and a remove waiting for a write (fails without the queue)pnpm compile,pnpm build🤖