-
Notifications
You must be signed in to change notification settings - Fork 28
Description
Problem
DbV2 will intentionally implement a reduced capability set and will return FeatureUnavailable for capabilities it does not provide. When that happens callers must still get data from the backing validator so services (Zallet, explorers) continue to work.
Options
A — NodeBackedChainIndex passthrough: extend the existing NodeBackedChainIndex logic to forward requests to the validator when DB returns FeatureUnavailable.
Pro: minimal changes. Con: responsibility lives outside DB; duplicate logic needed for other callers.
B — ZainoDB passthrough: implement passthrough inside finalised-state using ValidatorConnector, so callers always ask the DB and the DB delegates when a feature is unavailable.
Pro: clean, single API surface; callers don’t need version-awareness. Con: small added complexity in finalised-state.
Tasks (Option B)
- Wire ValidatorConnector into finalised-state/router.
- Implement a small wrapper that intercepts FeatureUnavailable, calls the validator (with a short configurable timeout), and returns the validator response.
- Ensure passthrough triggers only for FeatureUnavailable (not for other DB errors).
- Add unit/integration tests: success, timeout, validator error, and V1 (no passthrough).
- Add a config knob for timeout and enable/disable passthrough; emit a simple metric for passthrough events.
Acceptance criteria (Option B)
- Callers receive validator data transparently when DB returns FeatureUnavailable.
- Passthrough is configurable, time-bounded, and only invoked for FeatureUnavailable.
- NodeBackedChainIndex can be simplified to rely on DB passthrough.