-
Notifications
You must be signed in to change notification settings - Fork 518
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Always set timestamp on APMEvents for incoming http requests #7567
Conversation
This pull request does not have a backport label. Could you fix it @simitt? 🙏
NOTE: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not entirely convinced that the extensible Dynamic
thing is worthwhile - seems a bit complicated to me, and I'd generally prefer to have tests which make more specific assertions than passing in a callback to ApproveEventDocs.
IMO we should:
- add a unit test which covers the time sync behaviour, checking with/without capture_personal_data
- maybe add a system test for capture_personal_data, checking the difference when it is/isn't enabled
This pull request is now in conflicts. Could you fix it @simitt? 🙏
|
Refering to your former comment, I ended up not adding a systemtest. As you indicated, the decision about setting personal data is made purely on the muxer level, and therefore a system test is not necessary. Refactored the muxer handling slightly to make it more easily testable. |
4811191
to
538ad1f
Compare
💔 Build Failed
Expand to view the summary
Build stats
Pipeline errorThis error is likely related to the pipeline itself. Please go to the traditional console output here" You will see the error (either a wrong syntax or configuration) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Probably not worth it in this PR, but perhaps we should take a middleware style approach where a function is passed in. Then the responsibilities can be separated and composed.
Generally agree on a better handling. This is going to be backported as a patch release to |
dd591a7
to
6246d89
Compare
confirmed with 2ad82dc |
…ging * upstream/main: (25 commits) Update to elastic/beats@cb7e33d0864e (elastic#7672) Update backporting docs (elastic#7639) [Automation] Update elastic stack version to 8.2.0-dcff22d7 for testing (elastic#7670) Update aws-lambda-extension.asciidoc (elastic#7664) modelindexer: Reduce locking on flushActive (elastic#7649) dra: run release-manager if branch is available (elastic#7631) [apmpackage] add quotes around {{this}} (elastic#7598) dra: enforce version (elastic#7636) Update magefile for universal Darwin binaries (elastic#7643) Update to elastic/beats@2443dbb9e892 (elastic#7640) Update go.mod (elastic#7638) Introduce new Rally track and tooling (elastic#6731) dra: slack/email with the branch (elastic#7630) model/modelindexer: close gzip writer (elastic#7624) [Automation] Update elastic stack version to 8.2.0-4509f321 for testing (elastic#7620) Fix asciidoc hyperlink syntax (elastic#7609) Update to elastic/beats@f2ce0a0f69a5 (elastic#7618) ci: packaging pipeline should not notify build status in github comments (elastic#7596) docs: add 8.1.1 release notes (elastic#7601) Always set timestamp on APMEvents for incoming http requests (elastic#7567) ...
Motivation/summary
APM Server does not record the timestamp from incoming RUM events when
capture_personal_data: false
. This PR ensures the timestamp is always set in the initialAPMEvent
.The approval tests are ignoring the concrete timestamp, as it is dynamic and would be ever changing. The PR adds functionality allowing to implement a custom check for dynamic attributes before dumping and comparing them to the approved documents. It is used to ensure that the
@timestamp
is not zero, without checking for the actual value.Checklist
How to test these changes
manual test
>= 8.0
, enable rum and configureapm-server.capture-personal-data: false
(standalone or managed mode doesn't matter)@timestamp
is a valid timestampWhen the same test is run on current
main
branch (without this fix) the@timestamp
value would be thezero
value.system test
Without the fix, the newly introduced test was failing like this
Related issues
fixes #7566