Source document copied on 20 October 2026. Its dated evidence and limitations remain as written. Feedback and decisions can be given in chat.

Importer review: LSP, saved-source contract and the base-list repair

October 20, 2026 · WOB-86 · task_072eb5da807b · dispatch ctx_75d8adc88d83

This file rolls the importer review forward. It keeps the earlier pass's findings (dispatch ctx_1699d44daf40) with their current status, and adds what this pass found and changed. Everything here ran offline. No NocoDB request, login, token read or live write happened.

The short version

The earlier review left one risk open. The importer listed the workspace's bases by following next, while the saved REST notes said that route pages through pageInfo. If JA Venues sat past the first page, schema would not see it and would create a second base, and base creation is not idempotent.

This pass read the pinned NocoDB source for that route (tag 2026.09.1), and the paging premise does not hold. The route does not page. It returns every base the token can see in one response, with no pageInfo, no pageSize and no next. The brief asked for the importer to read the response's pageSize, but that field is not in the response, so reading it would mean inventing a payload.

The importer now reads that list once. If a response carries next or pageInfo, the run stops before anything is created, because the running server would then differ from the source. Data and link pagination still follow next, as before.

One duplicate risk remains, and the paging fix does not touch it. The source shows that what a token can see decides what the list contains, so a token that is not a member of JA Venues would not see the base and schema would create another one. Root has set the disposition for it (finding 14 below).

What the pinned source says

The controller for the route returns the service's array as-is:

// packages/nocodb/src/controllers/v3/bases-v3.controller.ts, tag 2026.09.1
const bases = await this.baseV3Service.baseList(context, {
  user: req.user,
  query: queryParams,
  workspaceId,
  req,
});
return { list: bases };

The query string does reach the service, but nothing downstream reads paging parameters:

Path Where the list comes from What happens to limit and offset
Super-admin token Base.list() in models/Base.ts Called with no arguments. The method carries a // todo: pagination comment and passes no limit to its query.
Any other token BaseUser.getProjectsList() in models/BaseUser.ts Accepts only workspaceId, starred, shared, recent and type. The paging parameters are never read.
Older v2 list at /api/v2/meta/bases/ controllers/bases.controller.ts Wraps the whole list in a page whose limit equals its count, so it also returns everything.

Three things follow. The saved REST note that says "Page with the pageSize in pageInfo" is not supported for this route at the pinned tag, and the note's own documented response shape ({list}) agrees with the controller. The v2 list does not offer a paged alternative either. And which bases appear depends on the token: a super-admin sees bases in every workspace, while any other token sees only the bases where it has a role.

Caveats. This is the source the tag contains. Whether the running instance matches the tag is unverified, because the saved notes say the image was never diffed against it. I read Base.list() but not the database helper it calls, so "no limit" rests on the call site and the todo comment. The source was read through the public-source read route, not from the instance.

What the importer does now

The new reader is a single read. It refuses any paging field instead of guessing how many rows exist:

def listed_once(api: Client, path: str, key: str) -> list[Payload]:
    page = api.request("GET", path)
    if not isinstance(page.get(key), list):
        raise ImportStopped(f"Expected {key} list in API readback")
    if "pageInfo" in page or page.get("next") is not None:
        raise ImportStopped(...)  # names the path; stops before any write
    return page[key]

resolve_base uses it for both the create-or-find path and inspect. The rediscovery step after an uncertain base create uses it too, so a base created on a second look is read the same way. The recover_create helper takes the reader as a parameter with the old listed as its default, so table creation, field lists and link reads behave as before. The listed function itself is unchanged.

The refusal is fail-closed. A next that is null is a complete single response and passes. A next that is a string, a number or an empty string stops the run, and so does any pageInfo, whatever its contents, because its meaning is undocumented for this route.

Tests

The importer's test module now runs 29 checks, all passing. Seven are new:

The existing 22 checks still run unchanged except for dataset expectations. The full-dataset counts moved from 930 records and 1,218 links to 990 and 1,415, because the Wispr delta added records and links. The unresolved-identity count moved from 9 to 10. The saved-feedback total moved from 19,505 to 20,343, because the Wispr delta added four feedback objects; the 19,505 check now lives in its own test for the original 12. No assertion was loosened, and no check was removed. The Monarch sample is still 44 records and 60 links, so its tests are unchanged.

Claude LSP evidence (this pass)

These came from the LSP tool in this worktree, after uv sync --locked (26 packages resolved, Python 3.14.8 interpreter). Lines and columns are 1-based.

Operation Target What came back
findReferences listed (before the repair) 9 references in the importer module: calls in recover_create, resolve_base, resolve_tables, prepare_schema, keyed_records and import_records.
findReferences recover_create (before the repair) 3 references: the definition, and its calls from resolve_base and prepare_schema.
documentSymbol scripts/venues/import_initial.py (after the repair) Matches the edited file: listed_once at line 95 sits between listed and only.
findReferences listed_once (line 95) 3 references: the definition, the call in resolve_base (274), and the read= argument (281).
hover listed_once (line 95) (api: Client, path: str, key: str) -> list[Payload], with its one-line docstring.
findReferences only (line 107) 11 references in the importer module.
findReferences listed (line 75, after the repair) 10 references across the importer and its test module.

Two notes on this evidence. First, the diagnostics channel reports only issues that an edit introduced, and a clean edit produces nothing. The earlier pass's edits introduced none, so nothing appeared. That is consistent with its CLI result, but it was not diagnostic proof. The readback in the next section is the proof, and it shows the channel works in this session. The Pyright CLI run below is separate evidence and does not stand in for the LSP. Second, one early lookup returned no references, and that was my error: adding an import shifted listed from line 74 to line 75, and I queried the blank line above it. The server's view was current, as the documentSymbol result shows.

Pyright CLI from the repository root, after the repair: 0 errors, 0 warnings, 0 informations, exit 0.

LSP diagnostics readback (dispatch ctx_4abd8ce87e8e)

This section supplies the diagnostic evidence the earlier pass lacked. It uses the supported route only: the edit workflow attaches a <new-diagnostics> block when the language server reports a new issue after a change.

Capabilities inspected first. The LSP tool exposes definition, reference, hover, symbol, implementation and call-hierarchy operations. None of them reads diagnostics. A deferred-tool search for diagnostics found no IDE diagnostics tool in this session. So the only diagnostic route is the edit notification, and it reports only issues an edit introduces.

Temporary probe, importer (labeled, then restored). I inserted one line after INITIAL = ... in scripts/venues/import_initial.py: _LSP_PROBE: int = "not an int" with a comment marking it as a temporary LSP probe. The Edit returned no block. The next LSP call on that file, a hover at line 20, returned:

<new-diagnostics>
The following new diagnostic issues were detected:

import_initial.py:
  ✘ [Line 21:19] Type "Literal['not an int']" is not assignable to declared type "int"
  "Literal['not an int']" is not assignable to "int" [reportAssignmentType] (Pyright)
  ★ [Line 21:1] "_LSP_PROBE" is not accessed (Pyright)
</new-diagnostics>

I then removed exactly that line. A hover after the removal returned no block. The file is byte-identical to 6aa30ee1 (sha256 304a54aa74980f47a3e3cf724178f2f9ed8e62777218bdbbb333e89289156b94), and the probe string does not appear in it.

Temporary probe, test module (labeled, then restored). I repeated the same maneuver in scripts/venues/test_import_initial.py, inserting the same line after DATASET = .... The next LSP hover, on line 32, returned the same error at line 33 and the same unused-name hint. I removed the line, and the next hover returned no block. The file is byte-identical to 6aa30ee1 (sha256 4973f161a33cd29c2caf99748f9ad34c8775aa4254fa1bca4d8aa8be87f78df8).

Clear state. After each restoration, the LSP call on the restored file produced no <new-diagnostics> block. That is the procedure's clean reading. The channel reports only issues introduced since the last readback and does not list pre-existing ones, so "clear" here means no new issues, not a full listing. The whole-repository Pyright run from 6aa30ee1 (0 errors, 0 warnings, exit 0) is the separate check that covers the rest.

Repair needed. None. The probes were not findings in the final code, and the final code is unchanged from 6aa30ee1. The offline evidence from that commit therefore still applies: 29 importer checks passing, Ruff lint and format clean, Pyright 0 errors. I did not rerun the suite.

Saved-source contract check, updated

Only one row changes from the earlier table.

Call Importer Saved source (2026.09.1) Result now
GET /api/v3/meta/workspaces/{ws}/bases resolve_base through listed_once Pinned controller returns {list} only. No paging fields, no next. Matches the pinned source. A response with paging fields stops the run. Live shape and the workspace value are still unverified.

The rest of the earlier table stands. The earlier pass checked each importer call against the saved REST map, and nothing this pass found changes those rows.

Findings and dispositions

Repaired in the earlier pass (status unchanged)

  1. Unknown dataset collections were dropped silently. Repaired; build_plan refuses an unmapped list.
  2. A connection with one missing endpoint was dropped silently. Repaired; a connection needs exactly two endpoint links.
  3. Forward link titles could repeat a table title (a precaution). Repaired by renaming eight forward links to Evidence claims, with a test.
  4. The acceptance plan would have written test values into the genuine base. Repaired; the rehearsal runs in a disposable base whose title must contain sample.
  5. The example-base refusal had no test. Test added.
  6. Test hygiene (four Pyright hints, a dead assignment). Fixed.
  7. Error messages named JA Venues for any target. Fixed.

Repaired in this pass

  1. Base-list paging. The earlier review left this open because the saved notes named pageInfo without its fields. The pinned source settles it: this route does not page. The importer now reads the list once and refuses any paging field before creating anything. The pageSize-based paging the brief asked for is not implemented, because the field it would read is not in the pinned response.

Still open

  1. Unset checkboxes. Fifteen connections have no Key contact value. If NocoDB reads an unset checkbox back as false, the first such write stops with a readback mismatch. That fails closed but would stop the sample.

  2. Plain strings in JSON fields. Eight activity summaries (of 14 rows) and 97 evidence claims (of 450 rows, 350 of which carry a claim) are plain strings. A readback that changes their form stops the run. This count was corrected in this dispatch: the earlier pass said four activity summaries, and the current dataset has eight.

  3. Exact text. Saved feedback is compared exactly after readback. A server that normalizes line endings would stop the import at that row.

  4. Malformed readback shapes. verify_fields reads link options with .get, so a null would raise an exception rather than a clean stop. The saved map gives link options as objects, so this should not occur.

  5. Write-error wording. A definite 4xx on a write is treated as uncertain and read back. That is safe, but the message says "uncertain" for a rejection.

  6. Duplicate risk from token visibility (new). The pinned source shows Base.list() for a super-admin token and getProjectsList() for any other token, and the second returns only bases the user belongs to in that workspace. If the token that runs schema cannot see an existing JA Venues base, resolve_base finds nothing and creates a second one. The importer does not check the token's role before it creates. Root's disposition: before the first schema creation, run a fresh native UI workspace inventory under Toberton's existing verified administrator session, and confirm that an API view matches that inventory. This is a required first-live-acceptance step, not a new product decision. It changes no auth or role settings and adds no framework. Root records it in import.md.

  7. The same generic next rule still applies to table and field lists. resolve_tables and prepare_schema still call listed, which follows next. The saved shape for the tables route is TableList{list} with no paging fields, but I did not read the pinned tables controller, so I left those calls alone. Extending listed_once to them is a small change once that controller is read.

  8. The saved REST note needs correcting. docs/nocodb-research-2026-10-18/rest-api.json (the workspace bases gotcha) and docs/nocodb-rest-api-2026-10-18.md say the route pages through pageInfo. The pinned source does not do that. Those research files are not owned by this worker, so the correction is for root. Status after this pass: superseded. Root repaired the two saved notes at 056ab36b: the v3 workspace bases entry in rest-api.json now records one {list} response with no paging fields, and the markdown note now scopes its 25-row default to data-record lists. Residual, not checked against source in this pass: the separate v2 open-source base-list entry in rest-api.json (near line 540) still lists pageInfo. The importer refuses any path outside /api/v3/, so that entry cannot reach this import.

Offline evidence after the repair

These are simulated-service checks, run from the repository root with the project's own interpreter. Exit codes are shown.

.venv/bin/python -m pytest scripts/venues -q -p no:cacheprovider   # 29 passed, exit 0
.venv/bin/ruff check scripts/venues                                # All checks passed, exit 0
.venv/bin/ruff format --check scripts/venues                       # 2 files already formatted, exit 0
pyright                                                            # 0 errors, 0 warnings, exit 0
.venv/bin/python scripts/venues/import_initial.py dry-run          # full plan, exit 0
.venv/bin/python scripts/venues/import_initial.py dry-run --venue brooklyn-monarch   # sample, exit 0

The two dry-runs gave these counts at e066192e, which is dated evidence: the full plan had 990 records, 1,415 links and 20,343 saved-feedback UTF-8 bytes, with the identity kinds physical venue 89, vessel 2, research lead 12, unresolved relationship 3, unresolved listing 3, unresolved branch 5 and unresolved identity 10. The Monarch sample: 44 records, 60 links, 4,662 saved-feedback bytes. The current counts at 283b0db5 are in the final section below.

These checks show the importer behaves as written against fixtures shaped like the saved source. They do not show that the live server accepts these bodies or returns these shapes.

Integrated-head acceptance at 283b0db5 (WOB-86, 20 October 2026)

This pass ran on the integrated source at 283b0db5. The importer, schema and dataset were not edited. The only code change is to scripts/venues/test_import_initial.py: the dataset-sensitive expectations moved from 990 records, 1,415 links and 20,343 bytes to the current 1,009, 1,481 and 20,738, and the identity-kind counts moved to the current dataset. No assertion was weakened or removed, and the 19,505-byte check for the original twelve stands.

The environment came first. uv sync --locked resolved 26 packages and checked 24, exit 0, before any lookup or edit.

LSP operations. The language server ran against this worktree after the sync, and these lookups are the evidence:

Diagnostics. The four edits to the test module returned no <new-diagnostics> block. Under the procedure, an empty result means a clean file, and no block arrived on any later call. That is what the server reported about the edited file, and nothing wider. The whole-project Pyright run below is separate evidence.

Focused tests, Ruff and Pyright. Before the test edits, the focused run was 27 passed and 2 failed. Both failures were dataset counts: total_records was 1009 against the stale 990, and the full import refused with Plan has 1009 records; exceeds --max-records 990. After the edits, 29 passed in 1.00s. ruff check . at the root passed. ruff format --check scripts/venues reported 2 files already formatted, and the root format check reported 76 files already formatted. pyright in the configured root project reported 0 errors, 0 warnings and 0 informations.

Dry-runs. Both ran offline, with no network call, and exited 0.

Run Records Links Saved feedback Bytes Identity kinds
Full 1,009 1,481 18 20,738 physical 90, vessel 2, research lead 12, unresolved relationship 2, unresolved listing 3, unresolved branch 6, unresolved identity 8, historical reference 1
Monarch sample 44 60 1 4,662 physical 1

Source checks. I read the decisive citations in the retained raw files. The Ivory owner quote (feedback:messages:ivory-shared-space:2026-07-07) matches its full text in line 56 of messages-gap-tola-team-july.jsonl, labeled as Toberton's message. The Lucky's owner quote (feedback:messages:luckys-potential-hold:2026-10-07) matches its full text in line 71 of messages-gap-luckys-brunch-oct6-12.jsonl. The Hudson location, Location: The Hudson (Dykman), is in line 7 of messages-gap-hudson-dyckman-may15.jsonl, and the Tola line naming "the ivory" is line 21 of messages-gap-tola-direct.jsonl. The four Wispr owner quotes were already found in their transcript files.

A plain search of the raw JSONL files did not find the full quotes, though the decoded message text contains them. The cause is JSON's optional escape for the slash. The Ivory line stores 6/19 as 6\/19, and the Lucky's line stores today / tomorrow as today \/ tomorrow. A JSON parser removes that escape, so the decoded bytes match the quote exactly. The mismatch is encoding, not data, and a raw search for the quote fails at the first slash. The checks above used the decoded comparison.

The original-twelve object owner:backyard:2026-10-06 is now traced. Its locator is docs/venue-extraction/sources/messages-brunch-group-page2.json, outside initial-base/sources, which is why my first search missed it. The decoded message at results[44] (guid 9A4DDAFF-B4D7-4584-A9A0-A74CF3D9F2B7, outgoing from Toberton, created 2026-10-06 22:40 UTC) equals the 145-character quote exactly. The object is unchanged.

Readbacks. I read the Slack readback's Tola, Lucky's and Hudson sections and the Wispr readback's boat and Resto passages. They match the dataset: the boat sailing time is unresolved, the Resto tour date is unstated, and the two Hudson keys are kept apart.

Footprint. No live call was made: no NocoDB request, login, token read, Slack or GitHub post, or outreach. The pytest, Ruff, Pyright and dry-run commands all exited. I removed my two measurement scripts from the session scratchpad. The language server belongs to this Claude session, and I left it running. Files changed in this pass: scripts/venues/test_import_initial.py, docs/venue-extraction/initial-base/import.md, importer-lsp-review.md and final-review.md.

Connected sample: what is left

The coordinator runs the steps in import.md, section "Evidence and remaining acceptance". In short: create the disposable base with schema --sample-title "JA Venues sample (disposable)" once authenticated access exists; import the 44-record Monarch sample into it; rerun it for zero writes; rehearse manual preservation there with a scratch dataset copy; then import the genuine base only after the rehearsal passes. The native UI inventory and matching API view from finding 14 come before the first schema run against the genuine instance. The first inspect response will show the real base-list shape, which settles finding 8 for the live server.

No step in this worker's run calls the server.

Footprint