docs: document TinyMath expression nesting and length limits (#7623) - #7676
Merged
Conversation
Contributor
Elastic Docs AI PR menuCheck the box to run an AI review for this pull request.
Powered by GitHub Agentic Workflows and docs-actions. For more information, reach out to the docs team. |
Contributor
✅ Elastic Docs Style Checker (Vale)No issues found on modified lines! The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale. |
Contributor
🔍 Preview links for changed docs |
florent-leborgne
enabled auto-merge (squash)
July 31, 2026 14:09
florent-leborgne
added a commit
to elastic/kibana
that referenced
this pull request
Jul 31, 2026
…#282035) ## Summary Documents the two new hard input limits on TinyMath expressions in the 8.19 Canvas function reference: up to 20 levels of parenthesis nesting and up to 1,000 characters, with expressions exceeding either limit rejected before parsing. This is the 8.19 (AsciiDoc) companion to the V3 docs update in elastic/docs-content#7676. On the `8.19` branch the TinyMath reference is still the legacy AsciiDoc, so the docs-content change (scoped `stack: ga 9.4`) does not reach 8.19 readers. The limits shipped in the `kbn-tinymath` package via #276783 (`backport:all-open`) and are present on the `8.19` branch: `MAX_NESTING_DEPTH = 20` and `MAX_EXPRESSION_LENGTH = 1000` in `src/platform/packages/private/kbn-tinymath/src/index.js`, checked before parsing. Per the issue availability table, the fix ships to users in 8.19.20. - **`docs/canvas/canvas-tinymath-functions.asciidoc`**: Add a note to the page introduction stating the nesting-depth and length limits. ## Related - V3 companion: elastic/docs-content#7676 - Docs issue: elastic/docs-content#7623 - Implementation: #276783 ## Labels needed Docs-only backport to the 8.19 branch. Please add `release_note:skip` and the `v8.19.20` version label on merge. --- > **AI-generated draft** — created with Claude. > Review all generated content for factual accuracy before merging.
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.
Summary
This PR addresses #7623 with the following change:
explore-analyze/visualize/canvas/canvas-tinymath-functions.md: Add a note to the page introduction documenting the two new hard input limits on TinyMath expressions — up to 20 levels of parenthesis nesting and up to 1,000 characters — with expressions exceeding either limit rejected before parsing.These limits were added in elastic/kibana#276783 to the shared
kbn-tinymathpackage. The performance fix itself needs no docs, but the limits are user-visible constraints that can reject previously accepted long or deeply nested formulas, and this is the only reference page describing TinyMath behavior.The values are verified against the current source (
MAX_NESTING_DEPTH = 20,MAX_EXPRESSION_LENGTH = 1000inkbn-tinymath/src/index.jsat HEAD).Version scoping
Tagged
stack: ga 9.4andserverless: ga.The fix was backported broadly (
backport:all-open), but under the cumulative-docs convention that readers run the latest patch of a documented minor, only minors with the limits in an actually shipped release get a badge:v9.3.9was a backport target, not a release (9.3 ended at 9.3.8), so no real 9.3 build carries the limits.9.4is the floor.9.4+in a single monotonic tag. Given this is a defensive input limit, leaving the trailing 8.x uncovered is an acceptable trade.Resolves
Closes #7623