mirror of
https://github.com/colbymchenry/codegraph.git
synced 2026-10-19 23:20:31 +08:00
04ec5f554d
* fix(extraction): an MPEG-TS video named .ts is not TypeScript (#1910) `.ts` mapped to TypeScript by extension alone, so MPEG transport-stream fixtures (`testdata/*.ts`) were parsed by tree-sitter: ~28 s of CPU for a 900 KB clip, minutes for a directory of them, for zero symbols. Recognise the stream from the head of the file — the 0x47 sync byte at offsets 0, 188, 376 and 564 plus a NUL byte, which every stream carries in its first packets and UTF-8 source never does — and drop it at discovery: not indexed, not parsed, not counted, not tallied as an unsupported language. The check reads under 1 KB and only for `.ts` files; the batch reader sniffs the bytes it already read, and the single-file path (sync, watcher) does the same head read, so a clip handed in by name is skipped too. The skip happens before parse dispatch, so no kernel mirror is needed. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(extraction): a video .ts is never pending on the git path or a scoped sync Review found two places that decide "is this a source file" without the MPEG-TS check the scan applies: the git fast path's candidate loop in getChangedFiles and the scoped-sync path filter (watcher events). An untracked clip in a git repo was reported as `added`, skipped by sync without a record, and reported as `added` again on every status; a tracked .ts that became a clip stayed `modified` with its stale nodes. Both now treat the clip as non-source: removed when tracked, ignored otherwise. Regression tests fail without this change and pass with it, on both arms. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(extraction): require a binary head before calling a .ts file video (#1910) Review on #1915: the sniff took four aligned 0x47 sync bytes plus any NUL as proof of a transport stream, so TypeScript with a `G` at four 188-byte strides and one raw NUL in a comment was dropped unindexed. The sniff now needs the sync byte on sixteen consecutive packets (3 KB of head) and at least 1/64 of the head to be control bytes. Compressed payload carries 8-20% of them (checked on ffmpeg-made H.264/AAC, MPEG-2 and MP2 streams); source text carries none. A shorter clip is cheap to parse anyway. Also drops the benchmark figures from the changelog entry. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(extraction): a file over the size limit is never read (#1910) The size gate ran after `readFile`, so a committed video or blob fixture was decoded in full — 3.4 GB of RSS for a 400 MB file, `Invalid string length` past ~512 MB — only to be stored as skipped. It was then read again by every pass that scans files by name: the framework detectors' `readFile` and the resolver's cached reader, three full passes on the reporter's fixtures. Stat first, everywhere a source file is read by path: the batch reader and `extractFile` store an oversize file with a size stamp in place of its content, change detection hashes the same stamp (so a same-size rewrite of a file nothing is indexed from is not a change, while crossing the limit in either direction is), and both by-name readers return null above the limit. The limit moves to `src/file-limits.ts` so the three sites share one number. strace on a sparse 400 MB `.ts`: 153 603 reads before, 0 after; indexing it next to a real file costs no measurable RSS. Stacked on #1914, which shares the batch-reader hunk. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * refactor(extraction): one-purpose size-stamp reader, comments in operation order `readSourceOrStamp` took a `stats` argument no caller passed and returned stats no caller read; it now returns the text or stamp change detection hashes. The batch reader's two comments are back in the order its code runs: the size gate, then the MPEG-TS head check. No behaviour change. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(extraction): bound the read itself, not only the stat before it (#1910) A file can grow between the stat that gates the size limit and the read that follows (a log, a download, a build output being written). Every source read now goes through readBoundedSource/readBoundedSourceSync: the open descriptor is re-checked, and the read stops one byte past the limit, so an oversize file is still stamped rather than decoded. The extraction batch reader, single-file extraction, framework detectors and the resolver's file cache all use it. Ported from the maintainer's hardening of this fix in #1919. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(extraction): bound the parse-retry reads too (#1910) The retry passes for files whose worker crashed or timed out re-read the source with an unbounded fsp.readFile. The file can have grown since the first, bounded read; an oversize file is now skipped by the retry instead of being decoded. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(extraction): check an oversize file against its size stamp everywhere (#1910) Review on #1915: - The viewer (readFileShape, hasDriftedOnDisk, the source endpoint) and MCP's drift gate hashed a file's real bytes, but the index stores the size stamp for a file over the limit, so every unchanged 1-8 MB file read as "changed on disk". oversizeStamp moves to file-limits.ts with an indexedHashInput helper, and all four checks hash what the index stored. An oversize file is now compared without being read. - git-index-currency's "keeps a committed path pending when sync cannot read it" injected its failure only into readFileSync, which the bounded reader no longer calls, so it failed. The failure now reaches openSync too. - The changelog entry drops its benchmark figures. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(mcp): check an oversize answer file against its size stamp (#1910) #2043's answer-freshness check hashes each contributing file whole and compares it with the stored contentHash. For a file over the index's size limit the stored hash is the size stamp, so an unchanged oversize file would read as stale. Compare it by its stamp, without reading it, like the viewer and the MCP drift gate do. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * perf(extraction): judge a .ts clip from the bytes it is read for, not at discovery (#1910) Discovery sniffed the head of every `.ts` file on every full scan — an open + 3 KB read + close per file, before anything asked for its content. On a 10k-file TypeScript tree that took a warm-cache scan from ~105 ms to ~243 ms; on a slow disk or a network share it is a random read per file per scan, the access pattern #1231 and the SMB reports (#1014, #448) are about. The bytes are now judged where they are read anyway, so the check costs no I/O and runs only for a file that is new or changed: the batch reader (as before), `indexFile`, the sync reconcile (an untracked clip is skipped, a tracked file that became one is removed through the same removal path as a deletion), and both `getChangedFiles` paths. The scan lists `.ts` files by name again; a test pins that discovery opens none of them on the walk or the git path. Scan time is back to main's (~98 ms), and a full index is unchanged within noise. Also collapses the four #1910 changelog bullets (#1914 and #1915 each added both) to two, without the benchmark figures. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: danusha2345 <danusha2345@users.noreply.github.com> Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com> Co-authored-by: danusha2345 <ewidusoc498@gmail.com>
473 lines
18 KiB
TypeScript
473 lines
18 KiB
TypeScript
/**
|
|
* `GET /api/source?file=&from=&to=` — verbatim source, or an honest refusal.
|
|
*
|
|
* This is the one endpoint that reads the user's repository, so two rules
|
|
* govern it and neither is negotiable.
|
|
*
|
|
* **Every read goes through `resolveProjectFile`.** That is the chokepoint from
|
|
* `security.ts` — traversal, in-tree symlinks pointing out of the root,
|
|
* absolute paths, sensitive system directories. Without it,
|
|
* `?file=../../.ssh/id_rsa` is a credential leak over a port the user opened to
|
|
* read their own code.
|
|
*
|
|
* **A file that changed on disk since it was indexed is never sliced under the
|
|
* index's numbering.** The viewer asks for line ranges the *index* recorded; if
|
|
* the file moved on since, those ranges can point at a different symbol's body,
|
|
* which would be served under the requested name and look perfectly plausible.
|
|
* So the bytes are hashed and compared against `files.content_hash`, and on a
|
|
* mismatch the slice is omitted with `drift: true` — the same call
|
|
* `codegraph_node` makes when it says "changed on disk after the last index
|
|
* sync".
|
|
*
|
|
* A caller that has ALREADY decided the index's numbering is off — a viewer
|
|
* about to draw a drift banner — asks with `ondrift=current` and gets the
|
|
* file's CURRENT lines instead of nothing. That is the other half of
|
|
* `codegraph_node`'s behaviour (issue #1474): a drifted file is served whole
|
|
* and current rather than omitted, because current bytes are correct by
|
|
* construction. `showing` says which of the two came back, on every response,
|
|
* so nothing has to infer it from the presence of `lines`.
|
|
*
|
|
* Only files that are IN the index are served. That is a tighter boundary than
|
|
* the MCP tools take, and it costs the viewer nothing (it only ever renders
|
|
* indexed symbols) while making the drift verdict meaningful for every answer:
|
|
* there is always a hash to compare against.
|
|
*/
|
|
|
|
import { createHash } from 'crypto';
|
|
import * as fs from 'fs';
|
|
import * as path from 'path';
|
|
import type { FileRecord } from '../../types';
|
|
import type { CodeGraph } from '../../index';
|
|
import { resolveProjectFile } from '../security';
|
|
import { indexedHashInput } from '../../file-limits';
|
|
import { highlightLines, type HighlightResult } from '../highlight';
|
|
import { ApiError, badRequest, intParam, notFound, textParam } from './respond';
|
|
|
|
/**
|
|
* Largest file we will read to answer a source request.
|
|
*
|
|
* The whole file has to be read to hash it, so this bounds the work one request
|
|
* can cause. Well above the 1 MB ceiling extraction itself applies, so anything
|
|
* actually in the index is comfortably inside it.
|
|
*/
|
|
export const MAX_SOURCE_BYTES = 8 * 1024 * 1024;
|
|
|
|
/** Lines returned in one response. The Symbol view asks for windows, not files. */
|
|
export const MAX_SOURCE_LINES = 4000;
|
|
|
|
/**
|
|
* Look up a file record by a viewer-supplied path, WITHOUT validating it.
|
|
*
|
|
* Indexed paths are normalized to forward slashes at extraction time, so that
|
|
* is the form tried first; the platform-separator form is a fallback for an
|
|
* index written before that normalization.
|
|
*
|
|
* Callers that go on to READ the file must use {@link resolveRequestedFile}
|
|
* instead — it puts the path through the security chokepoint first. This one is
|
|
* for endpoints that only need the record (a drift flag on a path the index
|
|
* itself handed us).
|
|
*/
|
|
export function findIndexedFile(
|
|
cg: CodeGraph,
|
|
requested: string
|
|
): { record: FileRecord; storedPath: string } | null {
|
|
const posix = toRequestPath(requested);
|
|
const record = cg.getFile(posix);
|
|
if (record) return { record, storedPath: posix };
|
|
|
|
const native = posix.split('/').join(path.sep);
|
|
if (native !== posix) {
|
|
const legacy = cg.getFile(native);
|
|
if (legacy) return { record: legacy, storedPath: native };
|
|
}
|
|
return null;
|
|
}
|
|
|
|
/**
|
|
* Forward slashes and no leading `./` — the form indexed paths are stored in.
|
|
*
|
|
* A LEADING SLASH IS LEFT ALONE on purpose. Stripping it would quietly turn
|
|
* `/etc/passwd` into the project-relative `etc/passwd` and answer "not in this
|
|
* index" — reinterpreting the request instead of refusing it, and leaving the
|
|
* chokepoint's absolute-path rule with nothing to catch.
|
|
*/
|
|
export function toRequestPath(requested: string): string {
|
|
return requested.replace(/\\/g, '/').replace(/^\.\//, '');
|
|
}
|
|
|
|
/**
|
|
* Validate a viewer-supplied path, THEN look it up in the index.
|
|
*
|
|
* The order is the point. `resolveProjectFile` runs first, so a traversal, an
|
|
* absolute path or a sensitive system directory is refused as what it is,
|
|
* before the index is consulted — a 403 that says "outside the project", not a
|
|
* 404 that says "not indexed" and quietly depends on the index lookup missing.
|
|
* It also means the absolute path every reader uses has already been through
|
|
* the chokepoint by construction, rather than by remembering to call it.
|
|
*
|
|
* @throws {PathRefusalError} the path is not one we would ever read.
|
|
* @throws {ApiError} `not-found` when it is fine but not in the index.
|
|
*/
|
|
export function resolveRequestedFile(
|
|
cg: CodeGraph,
|
|
projectRoot: string,
|
|
requested: string
|
|
): { record: FileRecord; storedPath: string; absolute: string } {
|
|
const posix = toRequestPath(requested);
|
|
// Refusals happen here, ahead of everything.
|
|
const absolute = resolveProjectFile(projectRoot, posix);
|
|
|
|
const found = findIndexedFile(cg, posix);
|
|
if (!found) throw notIndexedError(posix);
|
|
return { ...found, absolute };
|
|
}
|
|
|
|
export function notIndexedError(file: string): ApiError {
|
|
return notFound(
|
|
`${file} is not in this CodeGraph index.`,
|
|
'The viewer only reads files the index knows about. If the file is new, ' +
|
|
'it appears after the next sync; if it is excluded (gitignored, generated, ' +
|
|
'or too large to parse), it will not appear at all.'
|
|
);
|
|
}
|
|
|
|
/**
|
|
* Split source the way the index counted it.
|
|
*
|
|
* Rows are `\n`-delimited — that is how tree-sitter numbers them — so a CRLF
|
|
* file has the same line numbers here as in the graph. The trailing `\r` is
|
|
* dropped per line so it does not render as a stray glyph.
|
|
*/
|
|
export function splitLines(content: string): string[] {
|
|
const lines = content.split('\n');
|
|
for (let i = 0; i < lines.length; i++) {
|
|
const line = lines[i] as string;
|
|
if (line.endsWith('\r')) lines[i] = line.slice(0, -1);
|
|
}
|
|
// A file ending in a newline splits to a final empty string that is not a
|
|
// line of source. Every other trailing empty line IS one.
|
|
if (lines.length > 1 && lines[lines.length - 1] === '') lines.pop();
|
|
return lines;
|
|
}
|
|
|
|
/**
|
|
* The whole text of an INDEXED file, or `null` for anything unreadable.
|
|
*
|
|
* The dead code report's corroboration pass needs to count an identifier in a
|
|
* file's text, and this module is the only one in `api/` that opens a file — so
|
|
* the reader it uses lives here, behind the same chokepoint. Three refusals,
|
|
* all answering `null` rather than throwing, because the caller's rule is
|
|
* already "cannot read it → do not make the claim":
|
|
*
|
|
* - not in the index (the viewer never reads a file the graph does not know);
|
|
* - outside the project (`resolveProjectFile` throws; caught here);
|
|
* - bigger than `maxBytes`.
|
|
*
|
|
* Drift is deliberately NOT checked. The question being asked is "does anything
|
|
* in this file write this name", and the file's current bytes are the better
|
|
* answer to it than the bytes we indexed.
|
|
*/
|
|
export function readIndexedFileText(
|
|
cg: CodeGraph,
|
|
projectRoot: string,
|
|
requested: string,
|
|
maxBytes: number
|
|
): string | null {
|
|
try {
|
|
const found = findIndexedFile(cg, requested);
|
|
if (!found) return null;
|
|
const absolute = resolveProjectFile(projectRoot, found.storedPath);
|
|
const stats = fs.statSync(absolute);
|
|
if (!stats.isFile() || stats.size > maxBytes) return null;
|
|
return fs.readFileSync(absolute, 'utf8');
|
|
} catch {
|
|
return null;
|
|
}
|
|
}
|
|
|
|
/**
|
|
* Whether an indexed file has changed on disk since it was indexed — the same
|
|
* verdict `/api/source` returns, for endpoints that must *flag* drift without
|
|
* serving source (a symbol header, a file outline).
|
|
*
|
|
* Cheap first: size plus floored mtime is the identical freshness test the sync
|
|
* fast path uses, so an untouched file costs one `stat`. Only a stat mismatch
|
|
* pays for a hash, which is what keeps a `touch` or a checkout that rewrote
|
|
* identical bytes from reading as drift.
|
|
*
|
|
* Any failure answers `false`. A wrong "stale" flag would put a warning banner
|
|
* over correct source; the cases that would trip it (missing record, unreadable
|
|
* file) have their own handling in the endpoints that actually read.
|
|
*/
|
|
export function hasDriftedOnDisk(
|
|
projectRoot: string,
|
|
storedPath: string,
|
|
record: FileRecord
|
|
): boolean {
|
|
try {
|
|
const absolute = resolveProjectFile(projectRoot, storedPath);
|
|
const stats = fs.statSync(absolute);
|
|
if (stats.size === record.size && Math.floor(stats.mtimeMs) === Math.floor(record.modifiedAt)) {
|
|
return false;
|
|
}
|
|
// A file over the index's size limit is stored as its size stamp (#1910),
|
|
// so it is compared as one — without reading it.
|
|
const hashed = indexedHashInput(stats.size, () => fs.readFileSync(absolute, 'utf-8'));
|
|
return createHash('sha256').update(hashed).digest('hex') !== record.contentHash;
|
|
} catch {
|
|
return false;
|
|
}
|
|
}
|
|
|
|
/**
|
|
* The drift verdict AND the file's length, from one read.
|
|
*
|
|
* The whole-file view needs both before it draws anything: the drift banner,
|
|
* and the line count that fixes the height of the scrolling document (every
|
|
* line is a fixed 20px, so the total IS the layout). Asking
|
|
* {@link hasDriftedOnDisk} and then a source page would answer the first
|
|
* question against one read of the file and the second against another, which
|
|
* is exactly the window in which a file can change underneath the two.
|
|
*
|
|
* Unlike `hasDriftedOnDisk` there is no stat-only fast path: the bytes have to
|
|
* be read to be counted. That is the cost of knowing the length, and it is
|
|
* bounded by {@link MAX_SOURCE_BYTES} like every other read here.
|
|
*/
|
|
export function readFileShape(
|
|
projectRoot: string,
|
|
storedPath: string,
|
|
record: FileRecord
|
|
): { drift: boolean; totalLines: number | null; reason?: string } {
|
|
let absolute: string;
|
|
try {
|
|
absolute = resolveProjectFile(projectRoot, storedPath);
|
|
} catch {
|
|
// A refusal on a path the INDEX handed us is not a request to refuse — the
|
|
// caller already passed the chokepoint. Treat it as unreadable.
|
|
return { drift: false, totalLines: null };
|
|
}
|
|
try {
|
|
const stats = fs.statSync(absolute);
|
|
if (stats.size > MAX_SOURCE_BYTES) {
|
|
return { drift: false, totalLines: null, reason: 'The file is too large to read here.' };
|
|
}
|
|
const content = fs.readFileSync(absolute, 'utf-8');
|
|
const hashed = indexedHashInput(stats.size, () => content);
|
|
const drift = createHash('sha256').update(hashed).digest('hex') !== record.contentHash;
|
|
return {
|
|
drift,
|
|
totalLines: splitLines(content).length,
|
|
...(drift
|
|
? {
|
|
reason:
|
|
'This file changed on disk after the last index sync, so the line ' +
|
|
'numbers the graph holds no longer match it.',
|
|
}
|
|
: {}),
|
|
};
|
|
} catch {
|
|
return {
|
|
drift: true,
|
|
totalLines: null,
|
|
reason: 'The file is in the index but could not be read from disk.',
|
|
};
|
|
}
|
|
}
|
|
|
|
export interface SourceResult {
|
|
file: string;
|
|
language: string;
|
|
/** The file on disk differs from what was indexed. */
|
|
drift: boolean;
|
|
/**
|
|
* Which numbering the returned lines belong to.
|
|
*
|
|
* `'indexed'` — the file matches the index, so the two are the same thing.
|
|
* `'current'` — the file drifted and the caller asked for it anyway
|
|
* (`ondrift=current`): these are the bytes on disk right now, and NOTHING the
|
|
* graph holds about this file (symbol ranges, call-site lines, ports) lines
|
|
* up with them.
|
|
* `'none'` — the file drifted and no slice is served.
|
|
*/
|
|
showing: 'indexed' | 'current' | 'none';
|
|
contentHash: string;
|
|
indexedAt: number;
|
|
generated: boolean;
|
|
totalLines: number | null;
|
|
from?: number;
|
|
to?: number;
|
|
lines?: string[];
|
|
truncated?: boolean;
|
|
reason?: string;
|
|
/**
|
|
* The same lines, classified for the code block — one entry per line, each a
|
|
* list of `[classId, text]` pairs indexed into `highlight.classes`.
|
|
*
|
|
* It rides with the slice rather than living behind its own endpoint because
|
|
* the two are only ever wanted together, and because a second round-trip
|
|
* would let the viewer paint unhighlighted source and then reflow it. Absent
|
|
* whenever `lines` is — a drifted file is not served at all.
|
|
*/
|
|
highlight?: HighlightResult;
|
|
}
|
|
|
|
/**
|
|
* What to do when the file on disk no longer matches the index.
|
|
*
|
|
* `omit` (the default) is the safe answer for a caller that has not decided
|
|
* anything yet. `current` is for one that has: it is about to say, in the
|
|
* pixels, that these are the file's CURRENT lines and that nothing the graph
|
|
* holds about them applies.
|
|
*/
|
|
export type OnDrift = 'omit' | 'current';
|
|
|
|
/** Said once, so the two places that answer with current bytes cannot diverge. */
|
|
const DRIFT_CURRENT_REASON =
|
|
'This file changed on disk after the last index sync. These are its current ' +
|
|
'lines; the indexed line ranges — symbol bodies, call sites, ports — no longer ' +
|
|
'match them. The next sync picks it up.';
|
|
|
|
export function parseOnDrift(query: URLSearchParams): OnDrift {
|
|
const raw = query.get('ondrift');
|
|
if (raw === null || raw === '' || raw === 'omit') return 'omit';
|
|
if (raw === 'current') return 'current';
|
|
throw badRequest(
|
|
`Parameter "ondrift" must be "omit" or "current" (got "${raw}").`,
|
|
'Omit it to leave a drifted file unsliced; "current" serves the bytes on disk instead.'
|
|
);
|
|
}
|
|
|
|
export async function buildSource(
|
|
cg: CodeGraph,
|
|
projectRoot: string,
|
|
query: URLSearchParams
|
|
): Promise<SourceResult> {
|
|
const requested = textParam(query, 'file');
|
|
// Refusal first, index lookup second — see `resolveRequestedFile`.
|
|
const { record, storedPath, absolute } = resolveRequestedFile(cg, projectRoot, requested);
|
|
|
|
const from = intParam(query, 'from', { min: 1, max: 5_000_000, default: 1 });
|
|
const to = intParam(query, 'to', { min: 1, max: 5_000_000, default: 0 });
|
|
if (to !== 0 && to < from) {
|
|
throw badRequest(`Parameter "to" (${to}) must not be before "from" (${from}).`);
|
|
}
|
|
const onDrift = parseOnDrift(query);
|
|
|
|
const base: SourceResult = {
|
|
file: storedPath.replace(/\\/g, '/'),
|
|
language: record.language,
|
|
drift: false,
|
|
showing: 'indexed',
|
|
contentHash: record.contentHash,
|
|
indexedAt: record.indexedAt,
|
|
generated: record.generated === true,
|
|
totalLines: null,
|
|
};
|
|
|
|
let stats: fs.Stats;
|
|
try {
|
|
stats = fs.statSync(absolute);
|
|
} catch {
|
|
// Indexed but gone. That IS drift, and the strongest kind: nothing on disk
|
|
// corresponds to the ranges the graph holds — and `ondrift=current` has
|
|
// nothing to fall back to either.
|
|
return {
|
|
...base,
|
|
drift: true,
|
|
showing: 'none',
|
|
reason: 'The file is in the index but no longer on disk.',
|
|
};
|
|
}
|
|
if (stats.size > MAX_SOURCE_BYTES) {
|
|
throw badRequest(
|
|
`${base.file} is ${Math.round(stats.size / 1024 / 1024)} MB — too large to serve as source.`
|
|
);
|
|
}
|
|
|
|
let content: string;
|
|
try {
|
|
content = fs.readFileSync(absolute, 'utf-8');
|
|
} catch (err) {
|
|
throw new ApiError(
|
|
'internal',
|
|
`Could not read ${base.file}: ${err instanceof Error ? err.message : String(err)}`
|
|
);
|
|
}
|
|
|
|
// Byte-identical to extraction's `hashContent` (sha256 over the utf-8
|
|
// string). A touch or a checkout that rewrote the same bytes must not count
|
|
// as drift, which is exactly what hashing content rather than mtime buys.
|
|
// A file over the index's size limit is stored as its size stamp (#1910).
|
|
const hash = createHash('sha256').update(indexedHashInput(stats.size, () => content)).digest('hex');
|
|
const drift = hash !== record.contentHash;
|
|
if (drift && onDrift === 'omit') {
|
|
return {
|
|
...base,
|
|
drift: true,
|
|
showing: 'none',
|
|
reason:
|
|
'This file changed on disk after the last index sync, so the indexed line ' +
|
|
'ranges no longer reliably match. Source is omitted rather than risk showing ' +
|
|
"a different symbol's code; it returns after the next sync.",
|
|
};
|
|
}
|
|
|
|
const all = splitLines(content);
|
|
// Past the end of the file `from` names nothing, which is a caller bug worth
|
|
// surfacing rather than answering with the last line as if that were meant.
|
|
// `to` past the end is different — "line 30 to the end, whatever that is" is
|
|
// an ordinary way to ask, so it clamps.
|
|
//
|
|
// The exception is a drifted file the caller asked for anyway: it has already
|
|
// been told the numbering does not hold, and a save that SHORTENED the file
|
|
// between the length it was given and this read is an ordinary race, not a
|
|
// bug. Those get an empty slice.
|
|
if (from > all.length) {
|
|
if (!drift) {
|
|
throw badRequest(
|
|
`Parameter "from" (${from}) is past the end of ${base.file}, which has ${all.length} lines.`
|
|
);
|
|
}
|
|
return {
|
|
...base,
|
|
drift: true,
|
|
showing: 'current',
|
|
totalLines: all.length,
|
|
from,
|
|
to: from - 1,
|
|
lines: [],
|
|
truncated: false,
|
|
reason: DRIFT_CURRENT_REASON,
|
|
};
|
|
}
|
|
const start = from;
|
|
const requestedEnd = to === 0 ? all.length : Math.min(to, all.length);
|
|
const end = Math.min(requestedEnd, start + MAX_SOURCE_LINES - 1);
|
|
const slice = all.slice(start - 1, end);
|
|
|
|
return {
|
|
...base,
|
|
drift,
|
|
// The bytes are always the ones on disk. What changes with drift is what
|
|
// they can be *used* for: under `current` the caller must not map anything
|
|
// the index holds onto these numbers.
|
|
showing: drift ? 'current' : 'indexed',
|
|
...(drift ? { reason: DRIFT_CURRENT_REASON } : {}),
|
|
totalLines: all.length,
|
|
from: start,
|
|
to: end,
|
|
lines: slice,
|
|
truncated: end < requestedEnd,
|
|
// Keyed on the hash of the bytes ACTUALLY BEING SERVED, so the cache is
|
|
// invalidated by the file changing rather than by a clock, and two viewers
|
|
// looking at the same symbol share one tokenisation. It must be the disk
|
|
// hash rather than the record's: on a drifted file those differ, and keying
|
|
// current lines under the indexed hash would serve the previous edit's
|
|
// colours over this one's text.
|
|
highlight: await highlightLines(slice, {
|
|
language: record.language,
|
|
cacheKey: `${hash}:${start}:${end}`,
|
|
}),
|
|
};
|
|
}
|