Fix interpolation for data points at bucket boundaries

[kkrik-es]

Interpolation logic didn't cover the case where there's a single data point at the lower boundary and just a previous state, or a single point at the upper boundary and just a next state. If this happens, the data point matches the only interpolated value, so there are no 2 data points within the state to calculate the delta. The fix is to use the delta from the closest data point in the adjacent state.

While there, added the following fixes to the randomized testing suite:

• Take adjacent buckets into account only when calculating counter deltas across boundaries.
• Fix delta calculation across boundaries when first and last value are the same (0 delta).

Fixes #139732

[elasticsearchmachine]

Hi @kkrik-es, I've created a changelog YAML for you.

[kkrik-es]

Repeated above.

[elasticsearchmachine]

Pinging @elastic/es-storage-engine (Team:StorageEngine)

[martijnvg]

LGTM 👍 . I only left questions.

[martijnvg]

Is is possible that both previousState and nextState is null or that they both are not null?

[martijnvg]

In that case is this allowed and then maybe do else if block?

[kkrik-es]

If they are both null, we just return Nan below - can't do better for now.
If they are both not null, we'd get a value to the other boundary so lastTsSec == firstTsSec would be false. I'll add asserts for this.

[martijnvg]

This is just to make bwc tests pass, right? Cause once this is merged and back ported, the no mode will report RATE_WITH_INTERPOLATION?

[kkrik-es]

Correct for bwc. I didn't use the new tag on unaffected tests, but can do so if you prefer.

[martijnvg]

I think we can make this issue an non-issue, given that this bug isn't released?

[github-actions]

ℹ️ Important: Docs version tagging

👋 Thanks for updating the docs! Just a friendly reminder that our docs are now cumulative. This means all 9.x versions are documented on the same page and published off of the main branch, instead of creating separate pages for each minor version.

We use applies_to tags to mark version-specific features and changes.

Expand for a quick overview

When to use applies_to tags:

✅ At the page level to indicate which products/deployments the content applies to (mandatory)
✅ When features change state (e.g. preview, ga) in a specific version
✅ When availability differs across deployments and environments

What NOT to do:

❌ Don't remove or replace information that applies to an older version
❌ Don't add new information that applies to a specific version without an applies_to tag
❌ Don't forget that applies_to tags can be used at the page, section, and inline level

🤔 Need help?

• Check out the cumulative docs guidelines
• Reach out in the #docs Slack channel

[elasticsearchmachine]

💔 Backport failed

Status	Branch	Result
❌	9.3	Commit could not be cherrypicked due to conflicts

You can use sqren/backport to manually backport by running backport --upstream elastic/elasticsearch --pr 139798

[kkrik-es]

💚 All backports created successfully

Status	Branch	Result
✅	9.3

Questions ?

Please refer to the Backport tool documentation