Repository navigation
feat(query): add reusable planning signals - #3444
Conversation
github-actions
Bot
added
the
area/tooling
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
josephschorr
changed the title
1777bd2 to
775a489
Compare
josephschorr
changed the title
Define typed observations, estimates and provider registration. Add immutable planning views, bounded schema/revision storage, selective schema compatibility transfer, and shared clock/schema fixtures.
775a489 to
fb19883
Compare
josephschorr
changed the title
josephschorr
changed the title
tstirrat15
left a comment
tstirrat15
left a comment
There was a problem hiding this comment.
See comments, otherwise LGTM
| // Clock is a synchronized fake clock for deterministic signal tests. | ||
| type Clock struct { | ||
| mu sync.Mutex | ||
| now time.Time // GUARDED_BY(mu) | ||
| } |
There was a problem hiding this comment.
Do we need this if we have synctest?
| // KeyType is the runtime type of the provider's population key. | ||
| KeyType reflect.Type | ||
|
|
||
| // ObservationType is the runtime type of accepted observations. | ||
| ObservationType reflect.Type | ||
|
|
||
| // ValueType is the runtime type of published estimates. | ||
| ValueType reflect.Type |
There was a problem hiding this comment.
Can this be handled with generics instead of reflection?
There was a problem hiding this comment.
Or is the type information itself important?
There was a problem hiding this comment.
The type information is needed to validate lookups and dependencies in the shared registry. The provider-facing API already uses generics.
| // Identity is the full structural identity of the observed subtree. | ||
| Identity string |
There was a problem hiding this comment.
i.e. a CanonicalKey? Or is it meant to be agnostic to that?
There was a problem hiding this comment.
It’s intentionally separate: this identifies the full subtree, while canonical keys can omit children. I’ll clarify the comment.
Add a common foundation for query-planner optimizations to learn from previous requests. Each signal declares whether its observations apply to one datastore revision or can be reused across revisions, keeping recommendations tied to compatible data and schema versions.
Retained evidence has explicit memory limits, and estimates stay stable while a plan is being prepared. Schema changes can preserve compatible evidence, reduce its weight, or discard it. This establishes the foundation for subsequent signal-driven optimizations without changing permission results.
Validated with race detection, generated tests for revision isolation and snapshot stability, query and optimizer regression tests, and lint checks.