wiz: fix state retention between iterations - #10278
Conversation
Because it is the one true way.
🚀 Benchmarks reportTo see the full report comment with |
|
Pinging @elastic/security-service-integrations (Team:Security-Service Integrations) |
| state.?want_more.orValue(true) | ||
| ? | ||
| state.?cursor.first_timestamp.orValue(null) | ||
| : | ||
| ( | ||
| has(state.cursor) && has(state.cursor.last_timestamp) && state.cursor.last_timestamp != null | ||
| state.?cursor.last_timestamp.orValue(null) != null | ||
| ? | ||
| state.cursor.last_timestamp | ||
| : | ||
| string(now() - duration(state.initial_interval)) | ||
| ) | ||
| : | ||
| ( | ||
| has(state.cursor) && has(state.cursor.first_timestamp) && state.cursor.first_timestamp != null | ||
| ? | ||
| state.cursor.first_timestamp | ||
| : | ||
| null | ||
| ) | ||
| ) |
There was a problem hiding this comment.
This logic is subtle, so please take extra care here. Similar in the other two data streams.
| "filterBy": { | ||
| "timestamp": { | ||
| "after": state.?want_more.orValue(true) ? | ||
| "after": state.want_more ? |
There was a problem hiding this comment.
The logic here flows algebraically, but the condition is odd IMO. Please take extra care here.
|
Waiting on internal testing against a real API. |
💚 Build Succeeded
History
cc @efd6 |
|
|
Tested successfully against a real endpoint, so merging. |
|
Package wiz - 1.3.0 containing this change is available at https://epr.elastic.co/search?package=wiz |




Proposed commit message
Fix state retention between iterations and clean up CEL code structure.
Checklist
changelog.ymlfile.Author's Checklist
How to test this PR locally
Related issues
Screenshots