Fix/remixer punchlist

[yghaemi]

No description provided.

[jakeaturner]

Critical

1. Deferring deletes past the conflict loop turns a common reorder into a hard job failure that leaves the library half-mutated

server/api/services/remixer-service.ts:1780

The delete phase runs after the retry loop and after the Unable to resolve title/URL conflicts throw. Any rename or move that targets a path currently occupied by a page in deleteOrdered can no longer succeed, because the occupant is not removed until the throw has already fired.

Concrete failure: user deletes section 1.1 Alpha and renames 1.2 Beta to Alpha. Beta's target path is 01:_Alpha, still held by the undeleted Alpha.

1. Phase 1: Beta gets a 409, throwForMindTouchResponse raises TitleConflictError (line 157), Beta lands on deferredStack.
2. Retry loop (line 1701): Beta is the only stuck entry, so stillStuck.length === beforeCount on every pass and the deadlock branch fires each time.
3. relocatable resolves to Beta (real numeric id), so temporarilyRelocatePage moves a live library page to remixer-swap-tmp-- with allow=deleteredirects.
4. base62(8) gives a fresh name each pass, so the move keeps succeeding. With maxRetryPasses = pages.length + 10, a 200 page book issues 210 real MindTouch moves of the same page.
5. The loop exhausts and throws. Alpha is still live, Beta is parked at a throwaway title, and the job is failed.

Before this change Alpha preceded Beta in BFS order and was deleted first, so the rename went through.

The cascade problem the comment describes is real, but the fix needs deletes to run before conflict resolution can give up. Simplest correct ordering is the straight-line pass, then deletes, then the deferred retry loop:

let deferredStack: OrderedEntry[] = [];
for (const entry of nonDeleteOrdered) {
const outcome = await processOrderedEntry(entry);
if (outcome === "conflict") deferredStack.push(entry);
}

// Survivors have been reparented out of any doomed subtree by now, so a
// recursive delete can no longer take them with it.
for (const entry of deleteOrdered) {
await processOrderedEntry(entry);
}

const maxRetryPasses = pages.length + 10;
// ...existing retry loop

That preserves the cascade guarantee (all moves complete before any delete) and frees the deleted paths before the retry loop decides it is deadlocked.

Two smaller things in the same block: processOrderedEntry's return value is discarded at line 1783, and handleDeletedPage failures are swallowed by the bare catch (error) {} at line 1628 (pre-existing). Combined, a delete that fails for a non-transient reason is reported to the user as processed and dropped from finalBook, so the saved state claims a page is gone while it is still live in the library. At minimum push a message on that path.

Major

2. canAccessPage now bypasses the TOC cache on every authorization check

server/api/services/book-service.ts:231

getBookPageIDs(false) here forces a full recursive GET_Page_Tree fetch against MindTouch on every call. canAccessPage is a per-request authz gate on eight call sites well outside the remixer:

• server/api/co-author.ts:34, 77, 116, 198, 313
• server/api/books.ts:2315, 2355
• server/api/restacker.ts:628

The 120 second cache (TOC_CACHE_TTL_SECONDS, book-service.ts:69) existed to keep these off the wire. Every co-author AI summary request now pays a full book tree fetch. That is added latency on each request plus upstream rate limit exposure, and none of it is needed for the remixer correctness this PR is chasing.

The two remixer call sites that genuinely need freshness are validateRemixerBookOwnership (remixer.ts:109) and runRemixerJob (remixer-service.ts:1388), both user-initiated and infrequent. Leave canAccessPage on the cache and scope the bypass to those two. If publish staleness is the underlying worry, invalidate the cache entry after a successful job rather than disabling reads globally.

3. preserveConfigs copies change-detection baselines, not just user settings

server/api/services/remixer-service.ts:1937

REMIXER_PAGE_CONFIG_KEYS includes originalPathNumber, originalFormattedPath, and originalFormattedPathOverride. Those are not configuration. They are the baseline the client diffs against to decide what changed.

The overlay defeats reseeding in normalizeBookState (RemixerDashboard.tsx:372):

const seedFormattedOriginals =
!page.addedItem && page.originalFormattedPathOverride === undefined;

Because the merge makes originalFormattedPathOverride defined, this is false, so the formatted-path baseline is never reseeded from the freshly loaded library tree. After "Fresh from Library" the user has current structure measured against a stale draft's baseline. hasFormattedPathChanged then reports overridden pages as changed when they are not, or misses a real change, and the next publish issues spurious renames or skips required ones.

originalPathNumber happens to survive because the fresh path passes initializeOriginalPathNumber: true (line 383), but it is the same category mistake and will bite the moment a caller omits that flag.

Drop all three:

const REMIXER_PAGE_CONFIG_KEYS = [
"pathNumber",
"numberedPath",
"formattedPath",
"formattedPathOverride",
"siblingTitleIndex",
"formattedPathPrefix",
"formattedPathIndex",
] as const;

4. loadSelectedBook overlays project configs onto an arbitrary browsed book

client/src/components/remixer/RemixerDashboard.tsx:596

const treeRes = await api.getRemixerTreeFlattened(id, targetNodeId, lib);

No options, so the server defaults to preserveConfigs: true (validators/remixer.ts:30). targetNodeId is whatever book the user picked from the catalog, which is usually not the project's book. The handler still merges this project's saved remixerCurrentBook onto that tree by page id.

When the user browses their own project book from the catalog, ids do match and the library pane renders with the draft's path numbers instead of the library's. Pass { flatten: true, preserveConfigs: false } here. This call is a library browse, not a book load.

Minor:

5. options is a breaking body shape on /remixer/:id/page/tree

server/api/validators/remixer.ts:30

Zod strips unknown keys by default, so an old caller sending top-level flatten: false now silently gets flatten: true with no error. All three in-repo callers were updated, so this is only a risk for anything outside this repo hitting the endpoint. Worth a note in the PR body.

Also, preserveConfigs is silently a no-op when flatten: false, since the merge is gated on Array.isArray(tree) (remixer.ts:657) and the unflattened shape is a nested object. Fine as a fail-safe, but it deserves a comment so a future caller does not assume it works.

6. Query convention drift

server/api/remixer.ts:443

{ projectID: id, status: "success" } drops the { $eq: ... } wrapper the rest of the file uses consistently (see line 488, and the pending-job check at line ~190). req.params.id is always a string in Express so there is no injection here, but matching the file's defensive style keeps the pattern greppable.

[yghaemi]

Many users, including Delmar, experienced the same error, which was caused by caching. We met yesterday, and he was understandably frustrated with the issue.

I noticed that caching was the likely cause because the error would resolve itself after some time. I’ve been looking into it to identify the root cause and prevent it from happening again.

[jakeaturner]

Totally understood 👍 I don't think it will be too much of a real performance concern until we can find a more cohesive solution

[libretexts-bot]

🎉 This PR is included in version 2.151.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀