Skip to content

refactor(stackwalk): Associate stack walk events by timestamp#677

Open
rabbitstack wants to merge 3 commits into
masterfrom
use-timestamp-for-stack-id
Open

refactor(stackwalk): Associate stack walk events by timestamp#677
rabbitstack wants to merge 3 commits into
masterfrom
use-timestamp-for-stack-id

Conversation

@rabbitstack

@rabbitstack rabbitstack commented Jun 15, 2026

Copy link
Copy Markdown
Owner

What is the purpose of this PR / why it is needed?

Historically, we relied on a bucketed queue per stack ID to link the stackwalk to its respective event. This approach can lead to incorrect attributions if the stackwalk event is not emitted or dropped.

The optimal strategy is to index the event per its raw timestamp, await the stackwalk where the timestamp parameter is equal to the original event timestamp, and enrich the event with return addresses.

What type of change does this PR introduce?


Uncomment one or more /kind <> lines:

/kind feature (non-breaking change which adds functionality)

/kind bug-fix (non-breaking change which fixes an issue)

/kind refactor (non-breaking change that restructures the code, while not changing the original functionality)

/kind breaking (fix or feature that would cause existing functionality to not work as expected

/kind cleanup

/kind improvement

/kind design

/kind documentation

/kind other (change that doesn't pertain to any of the above categories)

Any specific area of the project related to this PR?


Uncomment one or more /area <> lines:

/area instrumentation

/area telemetry

/area rule-engine

/area filters

/area yara

/area event

/area captures

/area alertsenders

/area outputs

/area rules

/area filaments

/area config

/area cli

/area tests

/area ci

/area build

/area docs

/area deps

/area evasion

/area other

Special notes for the reviewer


Does this PR introduce a user-facing change?


The CreateFile event callstack is attached early in the approver stage,
reducing the amount of StackWalk events we propagate to downstream
components. The callstack is appended to CreateFile event parameters.
Historically, we relied on a bucketed queue per stack id to link the stackwalk
to its respective event. This approach can introduce wrong attributions if the
stackwalk event is not emitted or dropped.
The optimal strategy is to index the event per its raw timestamp, await for the
stackwalk where the timestamp parameter is equal to the original event timestamp, and enrich the event with return addresses.
This change is necessary to correctly attribute stack walk event timestamps.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant