Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,164 @@
---
navigation_title: Array manipulation errors
applies_to:
stack: ga
serverless: ga
products:
- id: elasticsearch
---

# Troubleshoot array manipulation errors in Painless
Copy link
Contributor

Choose a reason for hiding this comment

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

I feel like this title is too generic. It could be a bit more specific and focused on the issue as its experienced from user the point of view, perhaps something along the lines of:

Accessing an index greater than or equal to the array size causes an exception

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm thinking about titles such as these, for example:

It would also be better aligned with the WIP guidance:

Image


Follow these guidelines to avoid array (list) access errors in your Painless scripts.

An array `index_out_of_bounds_exception` error occurs when a script tries to access an element at a position that does not exist in the array. For example, if an array has two elements, trying to access a third element triggers this exception.

## Sample error

```json
{
"error": {
"root_cause": [
{
"type": "index_out_of_bounds_exception",
"reason": "index_out_of_bounds_exception: Index 2 out of bounds for length 2"
}
],
"type": "search_phase_execution_exception",
"reason": "all shards failed",
"phase": "query",
"grouped": true,
"failed_shards": [
{
"shard": 0,
"index": "blog_posts",
"node": "hupWdkj_RtmThGjNUiIt_w",
"reason": {
"type": "script_exception",
"reason": "runtime error",
"script_stack": [
"java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)",
"java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)",
"java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)",
"java.base/java.util.Objects.checkIndex(Objects.java:365)",
"java.base/java.util.ArrayList.get(ArrayList.java:428)",
"""return keywords[2].toUpperCase();
""",
" ^---- HERE"
],
"script": " ...",
"lang": "painless",
"position": {
"offset": 76,
"start": 61,
"end": 105
},
"caused_by": {
"type": "index_out_of_bounds_exception",
"reason": "index_out_of_bounds_exception: Index 2 out of bounds for length 2"
}
}
}
],
"caused_by": {
"type": "index_out_of_bounds_exception",
"reason": "index_out_of_bounds_exception: Index 2 out of bounds for length 2"
}
},
"status": 400
}
```

## Problematic code
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm questioning the usefulness of this section as well, it goes into overly-explaining territory.

If you want to keep the code, maybe hide it in a dropdown so it doesn't make the page look too bloated? Another thing is the title problematic code sounds like attributing blame and I'm sure that's not the intention at all. It's tricky to find the right balance between trying to help the user without making them feel like they did something wrong (even if technically we're addressing errors in this section).


```json
{
"aggs": {
"third_tag_stats": {
"terms": {
"script": {
"source": """
def keywords = params._source.tags;

return keywords[2].toUpperCase();
""",
"lang": "painless"
}
}
}
}
}
```

## Root cause
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm wondering about this structure. The info in this Root cause section is kind of redundant (it repeats the same info as the topic description, so I'm questioning its user value 🫣)

I only skimmed through some of the existing Troubleshoot > Elasticsearch topics, and I don't think they follow a specific pattern. I do like the idea that a template brings consistency across topics, but it stands out against the existing content -- not sure what the best strategy would be (new topics using a new format/structure or follow existing patterns). I know our team is working on developing guidance and templates for troubleshooting topics (check out this PR it also includes a new template for troubleshooting topics).

For consistency, I think the content would be better aligned with the docs team efforts -- this guidance makes more sense to me. Btw it also recommends that we do not explain causes, so you can safely get rid of this section.


The error occurs because the script tries to access index 2 (the third element) in an array that only has two elements (indices 0, 1). Arrays in Painless are zero-indexed, so accessing an index greater than or equal to the array size causes an exception.

## Solution: Check array bounds before accessing
Copy link
Contributor

Choose a reason for hiding this comment

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

Should Solution be substituted with Resolution?

Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe it's because I don't know Painless at all, but I would find callouts useful to orient the reader, what should they be paying attention to?


Always verify the size of an array before accessing specific indices:

```json
GET blog_posts/_search
{
"size": 0,
"aggs": {
"third_tag_stats": {
"terms": {
"script": {
"source": """
def keywords = params._source.tags;

if (keywords.size() > 2) {
return keywords[2].toUpperCase();
} else {
return "NO_THIRD_TAG";
}
""",
"lang": "painless"
}
}
}
}
}
```

## Sample document
Copy link
Contributor

Choose a reason for hiding this comment

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

This feels like it's a part of the solution, right? It's an example that illustrates (the Results section) the solution, so maybe it should be included in the Solution/Resolution section?


```json
POST blog_posts/_doc
{
"title": "Getting Started with Elasticsearch",
"content": "Learn the basics...",
"tags": ["elasticsearch", "tutorial"]
}
```

## Results

```json
{
...,
"hits": {
...
},
"aggregations": {
"third_tag_stats": {
"doc_count_error_upper_bound": 0,
"sum_other_doc_count": 0,
"buckets": [
{
"key": "NO_THIRD_TAG",
"doc_count": 1
}
]
}
}
}
```

## Notes
Copy link
Contributor

Choose a reason for hiding this comment

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

This content should be included higher up in the page ("before the fold"), perhaps incorporated into the page description and/or also in the Resolution section.


* **Array bounds:** Always check the size of an array before accessing specific indices.
* **Zero-indexed:** Remember that arrays start at index 0, so `size() - 1` is the last valid index.
* **Empty arrays:** Handle cases where arrays might be completely empty (`size() == 0`).
109 changes: 109 additions & 0 deletions troubleshoot/elasticsearch/painless-date-math-errors.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,109 @@
---
navigation_title: Date math errors
applies_to:
stack: ga
serverless: ga
products:
- id: elasticsearch
---

# Troubleshoot date math errors in Painless
Copy link
Contributor

Choose a reason for hiding this comment

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

The title would be more useful if it was rewritten with the error message in mind, maybe something like illegal_argument_exception when calling date methods without using .value or Fixing illegal_argument_exception in scripts by accessing date fields via .value


Follow these guidelines to avoid [date](elasticsearch://reference/scripting-languages/painless/using-datetime-in-painless.md) operation errors in your Painless scripts.
Copy link
Contributor

Choose a reason for hiding this comment

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

A lot of the structure-related comments apply to this topic as well. I think information in the Solution and Notes sections should be brought into the introduction. You can also summarise why (the root cause) this runtime error occurs.

The error message is more important than the problematic code (which is so similar to the solution it feels like a duplication). I think the solution code example with its explanation is enough.


When you work with date fields in runtime mappings, accessing methods directly on the document field object can cause errors if the proper value accessor is not used.

## Error

```json
{
"error": {
"root_cause": [
{
"type": "script_exception",
"reason": "runtime error",
"script_stack": [
"""emit(orderDate.toInstant().toEpochMilli() + 14400000);
""",
" ^---- HERE"
],
"script": " ...",
"lang": "painless",
"position": {
"offset": 75,
"start": 61,
"end": 124
}
}
],
"type": "search_phase_execution_exception",
"reason": "all shards failed",
"phase": "query",
"grouped": true,
"failed_shards": [
{
"shard": 0,
"index": "kibana_sample_data_ecommerce",
"node": "CxMTEjvKSEC0k0aTr4OM3A",
"reason": {
"type": "script_exception",
"reason": "runtime error",
"script_stack": [
"""emit(orderDate.toInstant().toEpochMilli() + 14400000);
""",
" ^---- HERE"
],
"script": " ...",
"lang": "painless",
"position": {
"offset": 75,
"start": 61,
"end": 124
},
"caused_by": {
"type": "illegal_argument_exception",
"reason": "dynamic method [org.elasticsearch.index.fielddata.ScriptDocValues.Dates, toInstant/0] not found"
}
}
}
]
},
"status": 400
}
```

## Problematic code

```json
"script": {
"lang": "painless",
"source": """
def orderDate = doc['order_date'];
emit(orderDate.toInstant().toEpochMilli() + 14400000);
"""
}
```

## Root cause

The script attempts to call `toInstant()` directly on a `ScriptDocValues.Dates` object. Date fields in Painless require accessing the `.value` property to get the actual date value before calling date methods.

## Solution

Access the date value using `.value` before calling date methods:

```json
"script": {
"lang": "painless",
"source": """
def orderDate = doc['order_date'].value; // Appended `.value` to the method.
emit(orderDate.toInstant().toEpochMilli() + 14400000);
"""
}
```

## Notes

* Always use `.value` when accessing single values from document fields in Painless.
* Check for empty fields when the field might not exist in all documents.
* Date arithmetic should be performed on the actual date value, not the field container object.
Loading
Loading