Rollback checks, more domain templates, type checks before execution, read-only deleted groups, and fewer 500 errors
Inputs over their length limit get a 400
Fact keys and display names over 100 characters and fact descriptions over 500 are rejected with400 (C-001) instead of 409 (C-006). Bulk fact registration skips a key that is too long as INVALID_KEY and creates the rest. Passwords over 72 characters and profile names over 255 are rejected with 400 (C-001) instead of failing with 500, and the console stops a password that is too long before you submit it. Phone numbers are limited to 50 characters, and sign-up accepts email addresses up to 254 characters. If you set a password longer than 72 characters before, reset it to sign in.Dataset files from the local MCP server
The local MCP server uploads a CSV or JSON file by its path withlexq_dataset_upload_file, so the file’s content never passes through the conversation. Datasets must be UTF-8. A file in another encoding is rejected with AN-040. See Dataset files and Supported Formats.Limits on the hosted MCP server
The hosted MCP server atmcp.lexq.io now caps a JSON-RPC batch at 100 messages and a tool argument at 10,000 elements. It rejects compressed request bodies (Content-Encoding) with 415, and request bodies stay limited to 100 KiB. See Dataset files for larger uploads.Rollback checks what you read
A rollback can now include the version and deployment you read from the group. If anyone deployed, rolled back, or undeployed after that, the rollback is rejected with409 (P-062 or P-063) and nothing changes. The console’s rollback dialog shows the version it restores and sends both values, and CLI 2.0.0 adds --expected-current-version-id and --expected-current-deployment-id. The lexq_deploy_rollback MCP tool on the local and hosted servers requires both values, so a call without them fails validation. See Rollback.A/B tests use versions from the same group
Starting an A/B test with a version from another policy group is rejected withP-016. See A/B Testing.Fact updates report rules outside a new value domain
When a fact update changes the value domain, the response lists, inmeta.valueDomainMismatch, the rules whose conditions use values outside the new domain. The console shows them in a dialog, the CLI prints them to stderr from 1.1.6, and the MCP tool adds them to the end of its result. The update is still saved. A changed domain reaches execution only in a version you publish after the change; deploying or rolling back to an existing version does not apply it, although the docs said redeploying was enough. Leaving out name or description now keeps the current value; send an empty description to clear it. See Rules outside a changed domain and Changing a domain later.The simulation list returns pageNo and pageSize
The simulation list now returns the same page fields as other lists.pageNo and pageSize replace number, size, pageable, sort, first, numberOfElements, and empty; content, totalElements, totalPages, and last are unchanged. The JSON output of lexq analytics simulation list and the result of lexq_simulation_list change the same way. To request a page from any list, send page and size. The docs named pageNo and pageSize, which the API ignores, so those requests always got the first page at the default size. See Pagination.More domain templates, and apply stops on a conflicting fact
Fintech Transfer Approval, SaaS Plan Limits, Insurance Claim Triage, and AI Agent Action Approval join a reworked E-Commerce Checkout Pricing. Applying a template stores value domains on its input facts, and the preview shows rule descriptions, value domains, and any of your facts that conflict. If you already have a fact with the same key but a different type or value domain, apply fails with409 (P-061) and creates nothing, and the console disables Apply. Until now, apply kept your fact and ran the template’s rules on it. Templates you applied before are unchanged. See Domain Templates.Fact values are checked before execution
A request that sends a value of another type for a registered fact the version reads, such as"85" for a NUMBER, now fails with 400 (P-060) before any rule runs. Earlier, the request returned 200 and that rule’s condition quietly did not match. null is not a mismatch, keys you have not registered are not checked, and the check uses the declarations copied when the version was published. Every key that an active rule reads must be sent, whether or not the fact is marked required, or the request fails with 400 (P-015). The docs said optional facts could be left out. See Unregistered Facts and Required vs Optional Facts.Fewer 500 errors
These requests failed with500 and now get an answer that names the cause:- A fact whose value is
nullno longer fails the request withC-004. Conditions on it do not match, the other rules run, andinputFactskeeps the order you sent. - A missing or non-JSON
Content-Typereturns415(C-010). - A missing required parameter or header, an unknown sort field, an out-of-range page number, or a
nulllist item returns400(C-001). - In a batch, an item’s
P-015,P-052, orP-060returns400with that code. A failed batch returns the first failing item’s error, without its position.
facts is now rejected with 400 (C-001). Search filters that cannot be converted return C-005 instead of C-001, and reorder requests with a priority of 0 or an empty ID return C-001 instead of P-034, P-025, or P-010. P-003 is a 500, as it always was; the docs listed it as 400. See the error reference.isBlocked and blockReason are pre-registered facts
Every organization now hasisBlocked (BOOLEAN) and blockReason (STRING), the two keys BLOCK writes, as pre-registered facts. A SET_FACT or MUTATE_FACT that targets either key is rejected on save and publish with 400 (ACT-033), so a later rule can no longer clear a block that an earlier rule set. Their type cannot be changed (403, FD-003). BLOCK records the block, and the remaining actions and rules still run; your application decides whether to stop. The console used to say that it stopped execution. See Pre-registered Facts and How a request runs.Deleted groups are read-only records
A deleted group now stays as a read-only record. Changing its settings, versions, or rules, publishing, deploying, scheduling a deployment, starting an A/B test, or deleting one of its versions returns409 (P-059). Its rows carry a Deleted badge, the group filter in Deployments and Executions lists Deleted groups, and the CLI’s table output marks them (deleted). Their decisions can still be replayed. Rules in deleted groups no longer stop you from deleting a fact or changing its type, so to remove a template, delete its group and then its facts. See Deleting a Group and Records of a Deleted Group.Disabled groups can still be tested
Dry runs, dry-run comparisons, and simulations now run on a disabled group, so you can check a fix before you enable it again. Live executions still need an active group. The console asks before it disables a group and shows a banner with Re-enable while it is disabled. A composite execution that includes a disabled group is rejected as a whole; to leave one group out of composite executions, undeploy it instead. See Disabling a Group.Action targets must be registered facts
Saving or publishing a rule whoseSET_FACT or MUTATE_FACT targets a key that is not a registered fact now fails with 400 (ACT-032), which lists the missing keys. Register the fact first. Versions you published before still deploy, but a draft cloned from one needs its targets registered before you publish it. An empty or non-string targetVar fails with 400 (ACT-016). See Action Types.Cancelling a replay or simulation stops it
Cancelling a replay or a simulation now stops the job, and you are billed only for the records it processed. Failed jobs are not billed. Pending and running jobs count toward your plan’s record limit when you submit another, so a submission past the limit fails with403 (B-008). A replay’s capped is true only when the window held more records than maxRecords. See the record limits for replays and simulations.Versions past their effective period are rejected
Publishing, deploying, or rolling back a version whose effective period has ended now fails with400 (P-058). A version update that leaves out an end of the period keeps it. To clear an end, send clearEffectiveFrom or clearEffectiveTo, pass --clear-effective-from or --clear-effective-to from CLI 1.1.0, or click ✕ in the console. Before this change, an update without them erased both ends. In the console, an end picked as 23:59 now covers that whole minute. An end you saved before stops at 23:59:00 until you pick it again. See Effective Date Range.Fixed CLI options
From CLI 1.1.0,lexq profile <groupId> --version-id <id> profiles that version, and lexq analytics simulation start --file request.json sends the file as the request body. Both failed in earlier versions, and --version only printed the CLI version number. From CLI 1.1.6, lexq facts update --pii and --no-pii change the fact’s PII setting; earlier versions never sent them. See Profile and PII Facts.Any IANA time zone for your organization
The console’s organization settings now offer every IANA time zone, searchable by city, region, or offset, instead of a list of 33 that were mostly in the US. The Performance tab now draws its reference time and latency chart in the organization’s time zone. From CLI 1.0.2, ayyyy-MM-dd date filter covers that whole day in the organization’s time zone, table output shows times in UTC with Z, and lexq status prints tenantTimezone. The CLI’s help did not say which time zone date filters used.Corrections to the docs
- The execution response carries changed facts in
mutatedFactsand new values, including__deltakeys, ingeneratedVariables. There is nooutputVariablesfield. See How a request runs. - To compare the two versions of an A/B test, run
lexq history list --version-idfor each.lexq history statscombines both. See Monitoring Results. - The Performance tab measures only executions that do not name a version. Specific-version executions, dry runs, simulations, and replays are not measured. Specific-version execution also skips the compiled rule cache, so split traffic with an A/B test instead. See How measurement works.
- Resolving or ignoring failure logs is console-only: an organization admin does it under Management → Failure Logs. API keys can only read failure logs, so
lexq logs action,lexq logs bulk-action, and the matching MCP tools are rejected with403(A-002). See Logs. - The CLI needs Node.js 22 or later. See Requirements.