Skip to content

Akamai: add recovery_interval parameter and handle 400 invalid timestamp - #16568

Merged
chemamartinez merged 4 commits into
elastic:mainfrom
chemamartinez:akamai-recovery-logic-configurable
Dec 16, 2025
Merged

Akamai: add recovery_interval parameter and handle 400 invalid timestamp#16568
chemamartinez merged 4 commits into
elastic:mainfrom
chemamartinez:akamai-recovery-logic-configurable

Conversation

@chemamartinez

@chemamartinez chemamartinez commented Dec 15, 2025

Copy link
Copy Markdown
Contributor

Proposed commit message

akamai: add configurable recovery interval for historical data re-fetch

The integration now supports a recovery_interval parameter (default: 12h)
that controls the lookback period when re-fetching historical data after
encountering API errors (416, 400 with "Invalid timestamp").

Additionally, enhanced error detection to properly identify and handle
400 Bad Request responses containing "Invalid timestamp" errors by
triggering recovery mode.

Checklist

  • I have reviewed tips for building integrations and this pull request is aligned with them.
  • I have verified that all data streams collect metrics or logs.
  • I have added an entry to my package's changelog.yml file.
  • I have verified that Kibana version constraints are current according to guidelines.
  • I have verified that any added dashboard complies with Kibana's Dashboard good practices
@chemamartinez chemamartinez self-assigned this Dec 15, 2025
@chemamartinez chemamartinez added Integration:akamai Akamai bugfix Pull request that fixes a bug issue Team:Security-Service Integrations Security Service Integrations team [elastic/security-service-integrations] labels Dec 15, 2025
@chemamartinez
chemamartinez marked this pull request as ready for review December 15, 2025 20:20
@chemamartinez
chemamartinez requested a review from a team as a code owner December 15, 2025 20:20
@elasticmachine

Copy link
Copy Markdown

Pinging @elastic/security-service-integrations (Team:Security-Service Integrations)

@elastic-vault-github-plugin-prod

Copy link
Copy Markdown
Contributor

🚀 Benchmarks report

To see the full report comment with /test benchmark fullreport

Comment thread packages/akamai/data_stream/siem/agent/stream/cel.yml.hbs Outdated
}
)
: (resp.StatusCode == 416) ?
: (resp.StatusCode == 416 || (resp.StatusCode == 400 && size(resp.Body) != 0 && bytes(resp.Body).decode_json().as(errorBody, has(errorBody.detail) && errorBody.detail.contains("Invalid timestamp")))) ?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Suggested change
: (resp.StatusCode == 416 || (resp.StatusCode == 400 && size(resp.Body) != 0 && bytes(resp.Body).decode_json().as(errorBody, has(errorBody.detail) && errorBody.detail.contains("Invalid timestamp")))) ?
: (resp.StatusCode == 416 || (resp.StatusCode == 400 && size(resp.Body) != 0 && bytes(resp.Body).decode_json().as(errorBody, has(errorBody.detail) && errorBody.detail.to_lower().contains("invalid timestamp")))) ?

I think we should use to_lower() just to be safe.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

We just need to check if to_lower() can be chained with contains() correctly once.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I've verified that they can be chained.

@ShourieG

Copy link
Copy Markdown
Contributor

I also updated the commit message a bit

@elasticmachine

Copy link
Copy Markdown

💚 Build Succeeded

History

cc @chemamartinez

name: akamai
title: Akamai
version: "3.0.2"
version: "3.1.0"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

@chemamartinez ,Just noticed this, I saw it was tagged as a bugfix, and the custom package shared was 3.0.3. Should we keep this the same or do we want to label it as an enhancement ? I feel an enhancement is appropriate as we are introducing a new config variable. If so we can add the enhancement label.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I've added the enhancement label

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Yes, it includes two changes and for me one is an enhancement and the other one a bugfix, so I changed the minor version and marked it as both in the changelog but forgot to add the label. Thank you!

@ShourieG ShourieG added the enhancement New feature or request label Dec 16, 2025

@ShourieG ShourieG left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

LGTM

@chemamartinez
chemamartinez merged commit 1fa74d5 into elastic:main Dec 16, 2025
8 checks passed
@chemamartinez
chemamartinez deleted the akamai-recovery-logic-configurable branch December 16, 2025 11:57
@elastic-vault-github-plugin-prod

Copy link
Copy Markdown
Contributor

Package akamai - 3.1.0 containing this change is available at https://epr.elastic.co/package/akamai/3.1.0/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bugfix Pull request that fixes a bug issue enhancement New feature or request Integration:akamai Akamai Team:Security-Service Integrations Security Service Integrations team [elastic/security-service-integrations]

3 participants