Skip to content

feat: add sourcePolicy to History API values requests#2817

Open
macjl wants to merge 3 commits into
SignalK:masterfrom
macjl:feature/history-source-policy-all
Open

feat: add sourcePolicy to History API values requests#2817
macjl wants to merge 3 commits into
SignalK:masterfrom
macjl:feature/history-source-policy-all

Conversation

@macjl

@macjl macjl commented Jul 1, 2026

Copy link
Copy Markdown
Contributor

Add a sourcePolicy query parameter to /history/values and pass it through to History API providers.

This allows clients to request source-aware historical values with sourcePolicy=all. Providers can then return separate value columns per source and include sourceRef in the values metadata.

Also update the History API response schema to document optional values[].sourceRef.

Closes #2780.

Validation:

  • npm run build
  • targeted eslint
  • tested against signalk-to-influxdb2 in a local Signal K sandbox

This PR adds a sourcePolicy query option to /history/values and threads it through the History API request types and handler logic. It validates sourcePolicy as preferred or all, returns a 400 error (including sourcePolicy details) for invalid values, and documents the parameter in OpenAPI. When sourcePolicy=all, it prompts History API providers to return values split by source and to include $source in the values metadata; path specs that already specify an explicit sourceRef remain an explicit filter.

It also updates the History API TypeBox schemas to use $source for values[].$source in the response, and keeps sourceRef on PathSpec for request-side source filtering. Tests verify that sourcePolicy=all produces per-source values entries with the expected $source values and that invalid input is rejected.

Allow History API values requests to pass sourcePolicy to providers so clients can request source-aware data.

Document sourceRef in the values metadata and validate sourcePolicy values before invoking the provider.
@coderabbitai

coderabbitai Bot commented Jul 1, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 3a3159fd-cc0b-4f16-ad94-5fba564d544a

📥 Commits

Reviewing files that changed from the base of the PR and between efa85e7 and cf68e1c.

⛔ Files ignored due to path filters (1)
  • test/plugin-test-config/node_modules/testplugin/index.js is excluded by !**/node_modules/**
📒 Files selected for processing (4)
  • packages/server-api/src/history.ts
  • packages/server-api/src/typebox/history-schemas.ts
  • src/api/history/openApi.ts
  • test/history-api.ts

📝 Walkthrough

Walkthrough

Adds sourcePolicy support to the History API /values endpoint, updates history value source metadata, and wires the new query parsing, schema, documentation, and tests.

Changes

History API sourcePolicy feature

Layer / File(s) Summary
Type and schema definitions
packages/server-api/src/history.ts, packages/server-api/src/typebox/history-schemas.ts
Adds HistorySourcePolicy ('preferred' | 'all'), optional sourcePolicy request fields, changes per-value source metadata to $source, and updates History API schemas for response and path specs.
Request parsing and validation
src/api/history/index.ts
Parses query.sourcePolicy, validates it against the allowed values, and includes it in the parsed values request or returns a validation error.
OpenAPI documentation and tests
src/api/history/openApi.ts, test/history-api.ts
Documents sourcePolicy and $source in the /values API contract and verifies the success and error paths in history API tests.

Estimated code review effort: 2 (Simple) | ~12 minutes

Possibly related PRs

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Linked Issues check ⚠️ Warning The PR renames the returned source metadata to $source, but #2780 explicitly asks to keep values[].sourceRef for split-by-source results. Keep the response field as values[].sourceRef and align the schema/tests, or update the issue/spec if the contract intentionally changed.
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly states the main change to History API values requests.
Description check ✅ Passed The description covers the problem, implementation, and validation/testing details.
Out of Scope Changes check ✅ Passed The changes all relate to History API source-aware values handling and documentation.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/api/history/index.ts`:
- Around line 285-291: Add an explicit validation or documentation note for the
ambiguous `sourcePolicy=all` plus per-path `sourceRef` case in
`parseValuesQuery` and `splitPathExpression`. If this combination is
unsupported, reject it early with a clear error before building the query;
otherwise, document which setting wins so the behavior is unambiguous for
callers and reflected in the OpenAPI docs.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 3b6b0a00-dc98-4f56-8d41-33b8ef0d00a5

📥 Commits

Reviewing files that changed from the base of the PR and between c86334b and 861f528.

⛔ Files ignored due to path filters (1)
  • test/plugin-test-config/node_modules/testplugin/index.js is excluded by !**/node_modules/**
📒 Files selected for processing (5)
  • packages/server-api/src/history.ts
  • packages/server-api/src/typebox/history-schemas.ts
  • src/api/history/index.ts
  • src/api/history/openApi.ts
  • test/history-api.ts

Comment thread src/api/history/index.ts
Comment on lines +285 to +291
let sourcePolicy: HistorySourcePolicy | undefined
try {
sourcePolicy = parseSourcePolicy(query.sourcePolicy)
} catch (error) {
errors.push(error instanceof Error ? error.message : 'Invalid sourcePolicy')
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

Consider validating/documenting sourcePolicy=all + per-path sourceRef interaction.

splitPathExpression (Line 392-394) lets a path already pin a single sourceRef via path|sourceRef. Combined with sourcePolicy=all, the semantics are ambiguous (should sourcePolicy be ignored, or override the pinned source?). Neither parseValuesQuery nor the OpenAPI docs address this combination.

Not blocking since provider behavior for this combination isn't defined in this PR's scope, but worth a validation error or explicit doc note to avoid confusing edge-case behavior downstream.

Also applies to: 296-299, 312-316, 368-396

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/api/history/index.ts` around lines 285 - 291, Add an explicit validation
or documentation note for the ambiguous `sourcePolicy=all` plus per-path
`sourceRef` case in `parseValuesQuery` and `splitPathExpression`. If this
combination is unsupported, reject it early with a clear error before building
the query; otherwise, document which setting wins so the behavior is unambiguous
for callers and reflected in the OpenAPI docs.

Document that sourcePolicy=all only expands paths without an explicit sourceRef so callers know that path-level source filters take precedence.
@macjl

macjl commented Jul 2, 2026

Copy link
Copy Markdown
Contributor Author

Follow-up: the CodeRabbit note about sourcePolicy=all combined with an explicit path sourceRef was addressed in efa85e7 by documenting that path-level source filters take precedence.

I also tried to add the feature label for the required-label check, but I do not have permission to add labels on this repository. Could a maintainer please add feature when convenient?

@tkurki tkurki added the feature label Jul 2, 2026

@tkurki tkurki left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In deltas we have $source whose type is SourceRef, so let's stick to that. Or am I missing something?

@macjl

macjl commented Jul 7, 2026

Copy link
Copy Markdown
Contributor Author

Updated in cf68e1c: history values metadata now uses $source: SourceRef instead of sourceRef, matching delta metadata.

I kept the request-side PathSpec.sourceRef / path|source filter unchanged, since that is the existing internal filter shape and avoids widening this change beyond the response metadata. I also updated the companion signalk-to-influxdb2 PR to emit $source in values[].

Does that address the concern, or would you prefer the request-side PathSpec.sourceRef naming to change as well?

* Controls how history providers should handle multiple sources for the
* requested paths.
*
* - `preferred`: provider default / priority-resolved source handling

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm. What would 'preferred' mean in practise? That provider would be able to figure out what source's value was preferred at the time, for arbitrarily varying lengths of time slices? To me that sounds like getting into the too complex domain.

Is this really needed? I'd like to leave it out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

History API: return values split by source

2 participants