Fix/remixer punchlist 3

[yghaemi]

No description provided.

[jakeaturner]

1. Step 2 moves an "unmoved" page under its live parent without checking whether that parent now sits below the page in the draft.

• Live book: someone in the library moves 21 (Alpha) under 23 (Gamma).
• Draft: the user moved 23 under 21. Page 21 keeps its number (2.1), so it doesn't count as moved in the draft.
• Result: 21's parent becomes 23 and 23's parent becomes 21 (["23","21"]).

Both pages and their subtrees lose their link to the root, so they disappear from the tree. The rebase also refreshes the fingerprint, so the 409 check won't stop the publish, and the job then tries to move a page under its own descendant. Potential fix:

const isUnder = (id: string, ancestorId: string): boolean => {
  const byId = new Map(book.map((n) => [n["@id"], n]));
  const seen = new Set<string>();
  for (let cur = byId.get(id); cur && !seen.has(cur["@id"]); cur = byId.get(parentKey(cur))) {
    if (cur["@id"] === ancestorId) return true;
    seen.add(cur["@id"]);
  }
  return false;
};
// in the step-2 loop, before placeAtLivePosition:
if (liveParent !== "-1" && isUnder(liveParent, node["@id"])) continue;

Also should add this case to the "both changed" tests.

2. Retrying after a failed publish always gets a 409 with the wrong explanation (RemixerDashboard.tsx:2735)

• A job that fails partway has already created, moved or deleted pages.
• The error branch doesn't reload anything, so the client still holds the pre-publish fingerprint.
• The user clicks Publish again and is told "the book was changed in the library". Their own partial publish made that change.
• Suggested fix: on job.status === "error", rebase the local draft (handleLoadSourceRef.current("local")) and say the book was partly published.

3. The 409 message steers users toward losing edits (RemixerDashboard.tsx:2145, server/api/remixer.ts:301)

• The check runs before the findOneAndUpdate that saves currentBook, so a refused publish saves nothing to the server.
• The message says "Reload your draft from Load Remixer State" without naming an option.
• Choosing Server or Server Draft loads the last saved state and drops everything since. Only the browser draft (autosaved every 500ms) has the latest edits.
• Potential improvement: on a 409, reload the browser draft for the user with handleLoadSourceRef.current("local"). If that ends up introducing too much complexity or is too risky, I suggest just prompting the user to reload the browser draft themselves.

[jakeaturner]

Looks good! One final edge-case hardening that would be good to follow up on: A failed rebase turns the guard off right after a 409 (RemixerDashboard.tsx:653)

rebaseDraftOnLiveToc still sets liveBookFingerprintRef.current = null in its catch. Both new recovery paths call it:

• Publish returns 409, so you know the book changed.
• The rebase's TOC fetch fails, and the fingerprint becomes null.
• The user ignores the "reload the page" notice and clicks Publish again.
• The client sends no fingerprint, the server skips the check, and the publish reverts the library changes the 409 just caught.

The job-error path has the same gap. Nulling made sense on initial load, where no baseline exists. After a 409 you want the stale fingerprint kept so publishes keep failing until a rebase succeeds:

const rebaseDraftOnLiveToc = async (
book, coverPageId, libreLibrary, pathLevelFormats,
{ keepFingerprintOnFailure = false } = {},
) => {
...
} catch (error) {
if (!keepFingerprintOnFailure) liveBookFingerprintRef.current = null;
...

Suggested fix: pass { keepFingerprintOnFailure: true } from rebaseCurrentBookOnLiveToc.

The merge-base changed after approval.

[libretexts-bot]

🎉 This PR is included in version 2.154.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀