Skip to content

Read the accepted Evidence keys again when an on-premise engine's data is refreshed - #130

Merged
jwrosewell merged 2 commits into
rcfrom
fix/refresh-evidence-keys
Nov 15, 2026
Merged

jwrosewell merged 2 commits into
rcfrom
fix/refresh-evidence-keys

Conversation

@jwrosewell

@jwrosewell jwrosewell commented Nov 14, 2026 •

Copy link
Copy Markdown
Contributor

Problem

Both on-premise engines read the Evidence keys they accept from the native engine once, when the native engine is created, and never again. A refresh of the data file calls refreshData() and keeps the filter made from the data file the engine started with.

So after an update to a data file that accepts other keys, the Pipeline keeps the Evidence the old file wanted, and drops Evidence the new file can use.

What the specification says

From device-detection-specification/pipeline-elements/device-detection-on-premise.md lines 78 to 86 at 706de1f0:

This Engine determines the accepted Evidence keys on data refresh based on values in the data source.

After loading the data source into the native code, call the getKeys function to return a list of the accepted Evidence keys. These values will then need to be stored to prevent repeated calls to the native code.

This MUST be done at start-up and any time the data is refreshed.

ip-intelligence-specification/pipeline-elements/ip-intelligence-on-premise.md lines 75 to 84 at 706de1f0 says the same for the IP Intelligence Engine, with the keys kept in the order the native code tries them.

What changed

In both engines a local readEvidenceKeyFilter reads the keys from the native engine, in the order it gives them and in lower case as before, and makes the filter. initEngine uses it, as before, and the refresh now uses it again straight after refreshData(). An engine that starts with no data file and builds its native engine on the first refresh goes through initEngine as before.

Tests

tests/refreshEvidenceKeys.test.js in each on-premise package builds the engine on a copy of the free data file (the Lite file for Device Detection, the ASN file for IP Intelligence), checks that its filter accepts every key the native engine gives, then wraps the native engine so that getKeys gives one more key and refreshes the data file through the data file the engine registers. The filter must then accept the new key, in any letter case, and still accept every earlier key.

Red, run 43649919865 on 1c6a1ab, the test commit on rc's code, with only a throwaway workflow added that builds the native modules and fetches the free data files as CI does. On Ubuntu both new tests fail at the same check, as the filter does not accept the new key after the refresh (Expected true, Received undefined).

Green, run 43649927428 on 5560b26, the fix, with only the same throwaway workflow added. Both tests pass, and lint passes on both on-premise packages.

Full build

Run 43651566189 on tmp/pr-matrix-130, started by tools/pr-matrix.py without macOS. All 7 Setting 'PullRequestSha' lines give this head, 5560b26, and Configure printed "Left out 2 macOS entries". Each of the six Build and Test jobs, Ubuntu, Ubuntu ARM and Windows on Node.js 22 and 24, passed 1,514 unit tests with 2 skipped and 96 integration tests with 4 skipped.

macOS was left out of this draft's full build under the 9 November decision. The rc head is built with macOS before it merges into main.

What remains

The Property metadata is not read again on a refresh either. An engine built with no Property names keeps the Property list it started with, as the C library does and as #108's reload test shows, so that is left as it is.

@jwrosewell
jwrosewell marked this pull request as ready for review November 15, 2026 00:01
@jwrosewell
jwrosewell merged commit 964a712 into rc Nov 15, 2026
2 checks passed
@jwrosewell
jwrosewell deleted the fix/refresh-evidence-keys branch November 15, 2026 00:01
@jwrosewell jwrosewell mentioned this pull request Nov 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant