[tenable_io] Coerce ratings score decimal strings to long in asset pipeline#19885
Closed
Jsmith-DigitalRealty wants to merge 1 commit into
Closed
Conversation
|
❌ Author of the following commits did not sign a Contributor Agreement: Please, read and sign the above mentioned agreement if you want to contribute to this project |
…peline The asset ingest pipeline converted `json.ratings.acr.score` and `json.ratings.aes.score` to `long` with a `convert` processor. Tenable Vulnerability Management can emit these scores as decimal strings (e.g. "9.0" / "744.0"). `convert` to `long` runs `Long.parseLong`, which throws `NumberFormatException: For input string: "9.0"` on any decimal form, appends to `error.message`, and tags the document `pipeline_error`. Replace the two `convert` processors with `script` processors that parse the value as a long, falling back to `Double.parseDouble` and truncating when the string carries a fractional part, mirroring the existing handling for the flat `acr_score` / `exposure_score` fields. Numeric inputs are also coerced, so integer and double JSON values continue to work. Update the asset pipeline test so the `ratings` record sends the scores as decimal strings, reproducing the failure and proving the fix.
Contributor
ReviewersBuildkite won't run for external contributors automatically; you need to add a comment:
NOTE: https://github.com/elastic/integrations/blob/main/.buildkite/pull-requests.json contains all those details. |
Jsmith-DigitalRealty
force-pushed
the
fix/tenable_io-ratings-score-decimal-string
branch
from
6e196d3 to
1260761
Compare
Jsmith-DigitalRealty
deleted the
fix/tenable_io-ratings-score-decimal-string
branch
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
1 participant
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.
Proposed commit message
WHAT: Replace the two
convert-to-longprocessors forjson.ratings.acr.scoreandjson.ratings.aes.scorein thetenable_io.assetingest pipeline withscriptprocessors that coerce the value to along, tolerating decimal-string inputs.WHY: Tenable Vulnerability Management can emit the ACR/AES rating scores as decimal strings (e.g.
"9.0"/"744.0"). Theconvertprocessor runsLong.parseLongunder the hood, which throwsNumberFormatException: For input string: "9.0"on any value containing a.. Each failure appended toerror.messageand the document was taggedevent.kind: pipeline_error, so valid asset records were being demoted to failure documents.The new
scriptprocessors parse the string as along, falling back toDouble.parseDoubleand truncating when a fractional part is present — mirroring the existing decimal-tolerant handling already in place for the flatacr_score/exposure_scorefields. Numeric JSON inputs (integer and double) are also coerced, so existing integer payloads continue to map unchanged.Checklist
changelog.ymlfile.Author's Checklist
acr_score/exposure_scoreinputs remain unchanged.ratingstest record now sendsratings.acr.score/ratings.aes.scoreas decimal strings ("9.0"/"744.0") to reproduce the failure; expected output remains9/744(long).How to test this PR locally
The
test-asset.logfixture includes a record whoseratings.acr.scoreandratings.aes.scorearrive as decimal strings; before this change that record produced anevent.kind: pipeline_errorwitherror.messagecontainingFor input string: "9.0". After this change the scores are coerced to longs and no error is recorded.Related issues