* 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
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
- Scripts are runnable - Each file can be executed as a smoke test
- Markers define sections - Code between
# [docs:section-name]and# [/docs:section-name]markers is extracted - Docs import at build time - MDX files use
raw-loaderto import scripts, thenCodeSnippetextracts 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
- Create or edit the appropriate script file
- Add markers around the new code section:
# [docs:my-new-section] client.some_method(...) # [/docs:my-new-section] - 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" /> - 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).