Repository navigation
fix(server): make call_rule_set and $data work, release 0.9.0 - #201
Merged
Merged
Conversation
ordo-server ran every ruleset with an executor that had no resolver, so a call_rule_set action always failed with "CallRuleSet requires a resolver". External data was injected as an input field named "$data", but rules read "$data.x" as a variable lookup, so the value was always missing and conditions on it were silently false. - core: `$name` paths fall back to an input field of the same name when no variable matches, so `$data.<name>.<path>` reads injected data (server and `ordo exec --data`). - core: `execute_with_resolver` passes a resolver per run, so one shared executor can serve every tenant. A call with `input_mapping` keeps `$data`. - server: one store read gives the ruleset, the tenant's data and a snapshot of every ruleset it can reach through calls. Used by execute, batch, pipeline, gRPC (single and batch), the decision gateway and debug execute. Batch and gRPC now also get `$data`. - server: with multi-tenancy, external data was saved under tenants/<id>/data but loaded from tenants/tenants/<id>/data, so it was lost on restart. - docs (en, zh): call_rule_set, external data, data endpoints. - bump crates and npm wrapper to 0.9.0 (also ships #198).
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Before: on ordo-server, a rule that calls another ruleset (
call_rule_set) always failed with "CallRuleSet requires a resolver to be configured". A rule that reads external data (amount >= $data.limits.vip_min) never saw the value, so the condition was silently false. With multi-tenancy, external data was lost on restart.After: both work on HTTP execute, batch, pipeline, gRPC (single and batch), the decision gateway and debug execute. Calls resolve within the caller's tenant, and a changed callee is picked up on the next request.
ordo exec --dataworks too. The docs describe both again (en and zh). Versions are bumped to 0.9.0 so the release also ships #198.How:
$namepath falls back to an input field of the same name when no variable matches. The server and CLI already inject external data as the input field$data; the expression lookup just never read it.RuleExecutor::execute_with_resolvertakes a resolver per run, so the one shared executor serves every tenant.RuleSet::called_rulesetslists direct callees. A call withinput_mappingkeeps$data.RuleStore::exec_target_for_tenantreads the ruleset, the tenant's data and a snapshot of every ruleset reachable through calls in one lock hold. A ruleset that calls nothing gets no snapshot. All execute paths use it, which also gives batch and gRPC$data, which they never had.tenants/<id>/databut loaded fromtenants/tenants/<id>/data.$data), store (tenant isolation, nested and self calls, data round trip after restart), HTTP integration (single, batch, pipeline, missing callee), gRPC.Checked with
cargo fmt --check,cargo clippy --all-targets --all-features -- -D warningsandcargo test --all-features --workspace, plus a local server run against a rules folder withdata/limits.json.Not covered: the CLI (
ordo exec,ordo test) and compiled.ordofiles still cannot runcall_rule_set; the docs say so.