Add context.readResource() to MethodContext for user extension models
Opened by swampadmin · 10/17/2025
Problem
User extension models that need to read back previously written data (e.g., reading discovery results during a pair operation) must use context.dataRepository.getContent() directly. This API uses positional arguments with an internal ModelType object:
context.dataRepository.getContent(context.modelType, context.modelId, dataName)This is brittle and asymmetric — context.writeResource(specName, name, data) provides a clean high-level API for writes, but there is no equivalent for reads. Extension authors must:
- Know to use
context.modelType(aModelTypeobject), notcontext.definition.id(a string) — the error when you get this wrong (type.toDirectoryPath is not a function) gives no hint about the actual problem. - Manually decode the returned
Uint8Arrayand parse JSON. - Understand internal repository semantics that
writeResourceotherwise abstracts away.
Proposed Solution
Add a context.readResource(dataName) method to MethodContext that mirrors writeResource:
readResource(dataName: string): Promise<Record<string, unknown> | null>This would:
- Use
context.modelTypeandcontext.modelIdinternally - Decode the
Uint8Arrayand parse JSON automatically - Return
nullif the data doesn't exist
Summary
Changes would be needed in:
MethodContextinterface insrc/domain/models/model.tsto add thereadResourcemethod signaturemethod_execution_service.tsto provide the implementation when building the context- Symmetry with
writeResource— same level of abstraction for both reads and writes
This keeps extension models working at the resource abstraction level without reaching into internal repository APIs.
Alternatives
- Document the
dataRepository.getContent()pattern more prominently (still brittle) - Use a named-object argument style for
getContentinstead of positional args (helps but still exposes internals)
Closed
No activity in this phase yet.
Sign in to post a ripple.