SUPERSEDED by #116: rank the due set by relative lateness (refuted approach)

[harper-joseph]

Superseded by #116. Closed — do not merge.

This PR ranked the drained claim window by relative lateness, (now − dueAt) / renderInterval, with a multiplicative sitemap boost. The diagnosis was right and the comparator was wrong, for two reasons that #80 had already recorded and this PR did not account for:

1. Relative lateness cannot be an order. It is linear in t with slope 1/interval, so two rows with different intervals cross exactly once — no stored key can express an order that changes with the clock, so no index can serve it.

2. Re-ranking the claim window cannot reach the row that matters. The window is anchored at the oldest due time and is already an EDF prefix. Under the deep backlog this exists to fix, every row in it is ancient, and a homepage two of its own cadences late is numerically nowhere near the head of the index. It is never read, so it is never re-ranked. candidatePool (added here to widen the window) does not help: a wider window anchored at the same place is more ancient rows.

That second point is decisive — it is the actual production symptom this was meant to fix, and this approach does not fix it.

#116 implements the design decided in #80 instead: the lane goes in the high bits of nextRenderTime, each lane gets its own watermark and its own seek, and fairness is allocator policy rather than part of the key. A lane's head is its oldest row, not the corpus's.

Two pieces from here survive into #116, reworked: the renderInterval the row is banded by is threaded from the same write sites, and the "measure lateness relative to the page's own cadence" idea remains as observability rather than as ordering.

Branch feat/render-priority can be deleted.

[gemini-code-assist]

Code Review

This pull request introduces a priority-based queue ordering mechanism (queue.priority) to determine which due rows in the render queue get leased first. Instead of using absolute due time, rows are ranked by how overdue they are relative to their own cadence, with an optional multiplier boost for sitemap-sourced rows. It also adds a new metric claim_lateness_pct to track lateness percentages and denormalizes renderInterval onto the RenderSchedule table to avoid hot-path database reads. The review feedback highlights an issue in intervalOf where row.renderInterval (a Long that can round-trip as a BigInt) needs to be coerced to a Number before calling Number.isFinite to prevent the check from failing.

[gemini-code-assist]

The renderInterval field is defined as a Long in the GraphQL schema, which means it can round-trip as a BigInt from the database. Since Number.isFinite returns false for BigInt values, we should coerce row.renderInterval to a Number first before performing the finiteness check. This ensures robust handling if orderByPriority is ever called with raw database rows in other contexts or future changes, adhering to the general rule for validating database column values.

Suggested change

	const intervalOf = (row, intervalFor) =>
	Number.isFinite(row.renderInterval) && row.renderInterval > 0 ? row.renderInterval : intervalFor(row.cacheKey);
	const intervalOf = (row, intervalFor) => {
	const interval = row.renderInterval != null ? Number(row.renderInterval) : undefined;
	return Number.isFinite(interval) && interval > 0 ? interval : intervalFor(row.cacheKey);
	};

References

1. When validating database column values (which may be surfaced as BigInt/Long) using Number.isFinite, always coerce the value to a Number first, as Number.isFinite returns false for BigInts.

[harper-joseph]

Closing: superseded by #116, which implements the decided design in #80. See the updated body for why the relative-lateness comparator here cannot fix the reported symptom — the claim window is anchored at the oldest due time, so the row that needs promoting is never read at all.