Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Enhancement] Make the flat_object read depth cap configurable instead of a constant

Open Beginner friendly
  • Is something wrong?
#5,842 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@RyanL1997 is already working on this.

Since Oct 12, 2026.

  • #5861 by @RyanL1997 — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
java
Domain
databases

Research direction

Start in FlatObjectValues.java where MAX_DEPTH is defined. Examine how plugin settings are declared in the project to choose between a cluster-wide plugin setting or reading the index's index.mapping.depth.limit. Update the constant to use the chosen configurable source, then add or update tests in the corresponding test class to verify the new behavior.

Written by the indexing model from the issue text.

Description

enhancement
What is wrong

Reading a flat_object descends the document, not the mapping, so nothing upstream bounds the recursion — the depth comes from whatever was written. #5830 caps it with a constant:

// opensearch/src/main/java/org/opensearch/sql/opensearch/data/value/FlatObjectValues.java
static final int MAX_DEPTH = 20;

20 is the default of index.mapping.depth.limit, the depth a mapped object is allowed, so a flat_object is read as deeply as one. Nothing is dropped at the cap: the object that would have been descended into is kept as one leaf holding its own JSON.

A constant is the wrong shape for it. An index that raises index.mapping.depth.limit is still read to 20, and an operator who wants a tighter bound has no way to set one.

What it should do

Make the cap configurable, as requested on #5830. Two shapes worth weighing:

  • a plugin setting, in the shape of the other plugins.* limits, so it is one value for the cluster and dynamically updatable;
  • or read the target index's own index.mapping.depth.limit, so a flat_object is read exactly as deep as a mapped object in the same index would be allowed — which is the reasoning the constant already stands on, just applied per index rather than at the default.

The second is the more faithful of the two; it needs the index setting to be available where the value is read, which the constant avoids today.

Follow-up to

#5830

Dominant language
Java
Stars
175
Forks
232
Avg merge
2d 20h
Merged PRs (30d)
44

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from opensearch-project/sql

All issues in opensearch-project/sql

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.