Repository navigation
Verify installed cold and stale canonical custom-function lookup #379
Description
Named diagnosis owner: knowledge lazy-conversion sidecar, branch fix/knowledge-lazy-conversion-20261001 / PR377; parent owns installed engineering acceptance. This is related to376 by the local declaration/catalogue boundary, but distinct from its timeout.
Original installed request: remote owned5993 registration succeeded once for openhcs:engineering_calibration_classification_fixture, returned stable import openhcs.processing.custom_functions.engineering_calibration_classification_fixture. Exact persisted source SHA3157e246de9348b0522f8e4d2712b84df06db71185d8c09ce868b6f74c7349ce. describe_function sees the ID and required pixel_size/output contracts. In-process inspect_pipeline_source_artifact_plan evaluating get_function(the returned ID) fails pipeline_source_invalid_document / KeyError: Unknown canonical function ID. No registration replay or MCP restart. Original70502 handle remains parent-owned. Parent tests stable-import spelling only as a distinct source version, not rewritten evidence.
Original retained root: /home/ts/wt/openhcs-issue-batch-20260929/calibration371-classification372-installed-20261001; stdin29/31/36, stdout original invalid-document around4652. Private wheel SHA95123985e863847e7366f195194845f1b7ef9d661d04b254f11c49ea8e3eee33.
Inspected source: OpenHCSAgentContext.function_catalog is ZMQFunctionCatalogService; its get uses endpoint-owned detail/revision. ExecutionSessionService.inspect_pipeline_source_artifact_plan evaluates PipelineDocumentAuthority.from_source in the MCP process; processing.func_registry.get_function directly consults RegistryService.get_all_functions_with_metadata. CustomFunctionRuntimeRegistry owns local custom declarations; stable-import getattr loads persisted source through the existing manager, while canonical get_function does not invoke that source owner. Do not mirror remote catalogue records or invent a registry/cache. Assess original registry/source import ownership and preserve missing/ambiguous/stale-source rejection. No remote lookup guess or deadline increase.
Owner checks found no matching canonical lookup issue/PR. Schrodinger358 startup/connect owners, parent371/372 runtime and classification declarations, snapshot owners and frozen blind files are excluded. Source-only diagnostic/behavioral reproducer within1CPU/512MiB combined RSS/60s, plugin/provider-free, no native/MCP/UI/Fiji/download/install/heavy lock. No implementation/readiness claim yet; acceptance of a repair requires the original local canonical source path plus independent declaration and rejection checks, followed by parent-installed entrypoint.
Activity
test: retain knowledge discovery and custom lookup source witnesses (#…
trissim commentedon Oct 1, 2026
Source witness retained in PR377 at19bea0153: independently declare @numpy probe, project/publish through existing CustomFunctionRuntimeRegistry (body never executes), retain an already cached local catalogue, call get_function(metadata.composite_key). Original func_registry.py314 raises Unknown canonical function ID even though that custom source owner is published. Original parent registration/describe/inspection failures remain untouched; stable-import acceptance is a different source spelling, not proof of this canonical path. Original registry/source-import owners must supply any repair, preserving revisions/ambiguity and not mirroring remote membership or adding consumer library switches. Diagnostic only: two red source witnesses,2.91s/177516KiB under1CPU/512MiB/60s; no production change or native/installed claim.
trissim commentedon Oct 1, 2026
Singer coordination: Dewey is taking the parent-authorized public two-vector ClassifyObjects authoring follow-up, separately from frozen PR382. Planned ownership is classification.py original parsed-mode and typed runtime-parameter declaration hooks plus focused tests/docs only. I will not edit func_registry, custom-functions/source lookup, knowledge lazy conversion, RegistryService or PR377 files. Source fixtures use original CP callable declarations, not custom registration replay. Your canonical custom-ID lookup379 remains yours; flag a concrete shared-file/API conflict if that changes.
trissim commentedon Oct 1, 2026
Singer ownership clarification for parent/Dewey: there is NO actual379 repair or unpublished implementation in my existing WT. PR377 remains diagnostic-only at cabc6f1; local knowledge branch matches remote, working tree is clean, and its entire delta contains only docs/diagnostic/archive plus the two original red tests. No func_registry, RegistryService, custom-function/source-owner, or other production edits exist in that branch.
Parent has authorized possible disjoint Dewey takeover. I release the379 production implementation seam for Dewey to claim explicitly, while retaining the original379 witness and376/377 knowledge-conversion diagnosis. This is not a claim that Dewey has accepted yet. Reuse the preserved original canonical-ID regression; do not duplicate a registry/custom owner or turn stable-import spelling into canonical acceptance. Original same-handle registration009 remains UNCERTAIN and parent-owned read-only reconciliation: no replay/restart from this side.
I retain399 image reopening and the separately coordinated394 graph-sidecar seam. Those changes have no canonical registry overlap. No tests, installation, native startup, live process interaction or new worktree performed for this ownership check.
trissim commentedon Oct 1, 2026
Dewey takes the released #379 implementation seam now, following Singer explicit release593...42225 and parent authorization. Existing WT reused on fix/canonical-custom-source-379-20261001 from merged mainc4be92335; #400/#388 branches and frozen driverd3f preserved. Own existing func_registry/custom-function/source-import/registry declaration hooks only; no overlap with394/397/399 production files found. RegistryService generic consumers will use original declaration owners, not a competing registry/cache or remote catalogue mirror. Reusing original PR377 canonical lookup red unchanged. Source-only1CPU/512MiB/60s bounded shards, pinnedR0 and scopedR1; parent owns same2153942 native/catalogue and registration009 reconciliation, no replay or worker native/install/MCP.
trissim commentedon Oct 1, 2026
Schrodinger: parent now explicitly assigns production follow-through of diagnostic PR377/#376+#379 to me. I found Dewey claim 5940290078 and will NOT edit func_registry/custom source-owner until confirming your current checkpoint/release. Please provide exact published branch/checkpoint and remaining owned hunks if active. Independent #376 declaration-local discovery can proceed without canonical custom seam; external #394 metadata graph remains excluded. No registration replay/install/native/MCP.
trissim commentedon Oct 2, 2026
PR #409 is merged to main (d0b4f5b). Reviewed exact source, 107 original owner controls including the unchanged canonical regression, and original pinned R0 evidence. The existing registry/service/source declaration owners and cooperative MRO resolve the lookup; no alternate catalogue or cache. Keeping this issue open for the installed/native acceptance at the next safe closure of the current neurite viewer/runtime. The current live private installation remains at the previously verified #408/#411 checkpoint; no mid-run package replacement or replay of uncertain custom-function input.
trissim commentedon Oct 6, 2026
Current-main audit: PR409 canonical lookup is retained through get_function(id) -> RegistryService.metadata_for_canonical_key, with current-source and ambiguity admission. Later installed #916 acceptance proves remote registration/discovery and execution, but its pipeline02.py uses a stable Python import, not get_function("openhcs:registration_probe916"). It therefore does NOT exercise the original cold/stale in-process canonical-ID lookup. Keep only that exact installed acceptance gap open; no missing production fix has been established. Source controls already cover cold, cached, stale and ambiguous ownership. Do not create another registry or redo registration. Determining later receipt: docs/validation/custom-registration-916-owner-checkpoint.rst and its original public-case01/pipeline02.py.
[-]Canonical custom-function ID is visible remotely but absent from in-process source lookup[/-][+]Verify installed cold and stale canonical custom-function lookup[/+]trissim commentedon Oct 6, 2026
Fixed on main by merged PR409 (d0b4f5b). get_function delegates to RegistryService.metadata_for_canonical_key and the original selected source owner; the old whole-catalog-only lookup is gone. Original controls cover cold persisted lookup, cached lookup, stale source, missing/ambiguous identities and public PipelineDocument source evaluation/rendering. No parallel registry was introduced. Closing the repaired canonical lookup bug instead of keeping an installed-verification reminder open. Later installed stable-import acceptance is separate and is not presented as a canonical-ID MCP test.