Files
Nicolò Boschi ef3ccdba3a fix(api): type the list and graph rows instead of returning bare dicts (#4218) (#4233)
* fix(api): type the list and graph rows instead of returning bare dicts (#4218)

`list_memories`, `list_documents`, `get_graph` and `get_entity_graph` declared
their rows as `dict[str, Any]`, so every generated SDK handed callers untyped
dicts while the single-fetch siblings returned real models — `listing.items[0].id`
failed with an `AttributeError` and a server-side rename became a runtime
`KeyError` rather than a build error.

Each row now has a model (`DocumentListItem`, `MemoryUnitListItem`, the Cytoscape
node/edge envelopes and `MemoryGraphTableRow`), sharing an `OpenRowModel` base
that keeps the wire byte-identical:

- `extra="allow"`, so a key the server emits and the model does not declare still
  reaches the client — a memories store that owns its own document or entity
  registry builds these rows itself.
- the routes keep emitting nulls. `ExcludeNoneRoute` was already enabling
  `response_model_exclude_none` for them, but `exclude_none` never reached inside
  a `dict` value, so the rows' nulls were always on the wire; typing them would
  have started dropping those keys.

`additionalProperties` is stripped from the published schema: openapi-generator
7.10.0's Python generator crashes on a schema pairing it with a nullable `anyOf`
property, which every row here has.

The CLI moves to attribute access, which exposes a latent bug in `bank graph`:
its node lookups read `node["type"]`/`node["id"]` through the Cytoscape `data`
envelope, so the sample always printed "unknown [unknown]" with no text.

* docs(examples): read list rows by attribute now that they are typed
2026-09-08 18:48:52 +02:00
..
2026-01-28 15:42:14 +01:00
2026-02-25 16:58:06 +01:00
2026-02-25 16:58:06 +01:00
2026-01-26 14:27:08 +01:00
2026-02-20 17:02:01 +01:00
2026-02-20 17:02:01 +01:00

API Documentation Examples

This directory contains runnable example scripts that serve as the source of truth for code samples in the documentation.

How It Works

  1. Scripts are runnable - Each file can be executed as a smoke test
  2. Markers define sections - Code between # [docs:section-name] and # [/docs:section-name] markers is extracted
  3. Docs import at build time - MDX files use raw-loader to import scripts, then CodeSnippet extracts marked sections

File Structure

File Documentation Description
quickstart.py/mjs/sh quickstart.md Getting started examples
retain.py/mjs/sh retain.md Memory ingestion examples
recall.py/mjs/sh recall.md Memory retrieval examples
reflect.py/mjs/sh reflect.md AI reflection examples
memory-banks.py/mjs memory-banks.md Bank management examples
documents.py/mjs documents.md Document CRUD examples
reflections.py reflections.md Reflections CRUD examples
main-methods.py main-methods.md Core method examples
cli-reference.sh cli.md CLI command examples

Running Examples

# Run all Python examples
for f in *.py; do python "$f"; done

# Run all Node.js examples
for f in *.mjs; do node "$f"; done

# Run all CLI examples
for f in *.sh; do bash "$f"; done

Requires a running Hindsight server at http://localhost:8888 (or set HINDSIGHT_API_URL).

Legacy Examples

The legacy/ folder contains deprecated example files kept only for backward compatibility with older documentation versions. These files are not runnable and are skipped by CI tests.

What's NOT Covered

1. OpenAPI Auto-Generated Docs (/api-reference/*)

These pages are generated directly from the OpenAPI specification. The spec itself is the source of truth, and the generated docs reflect it automatically. No manual code examples to validate.

2. Interactive CLI Commands

Command Reason
hindsight configure Requires interactive user input (prompts for API URL, credentials)
hindsight configure --show Displays sensitive configuration, not suitable for automated tests

3. Installation/Setup Instructions

Documentation sections covering pip install, npm install, or system setup are instructions, not executable code samples. These are validated by the CI environment setup itself.

4. Error Handling Examples

Some docs show error responses (e.g., "what happens when bank doesn't exist"). These require intentionally broken states that would fail smoke tests. Error behavior is covered by unit tests instead.

Adding New Examples

  1. Create or edit the appropriate script file
  2. Add markers around the new code section:
    # [docs:my-new-section]
    client.some_method(...)
    # [/docs:my-new-section]
    
  3. Reference in the MDX file:
    import myScript from '!!raw-loader!@site/examples/api/my-script.py';
    <CodeSnippet code={myScript} section="my-new-section" language="python" />
    
  4. Run the script locally to verify it works

Marker Format

  • Python/Bash: # [docs:section-name] / # [/docs:section-name]
  • JavaScript: // [docs:section-name] / // [/docs:section-name]

Section names should be kebab-case and descriptive (e.g., retain-with-context, recall-basic).