-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
fix(tmplexec): handle race condition on tmplexec #5885
base: dev
Are you sure you want to change the base?
Conversation
WalkthroughThe pull request introduces modifications to the Changes
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
4c8a166
to
82c3f9a
Compare
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.
// copy lastMatcherEvent pointer to avoid race condition where lastMatcherEvent is changed after the lock. | ||
event := lastMatcherEvent | ||
event.Lock() | ||
event.InternalEvent["error"] = getErrorCause(ctx.GenerateErrorMessage()) | ||
event.Unlock() | ||
writeFailureCallback(event, e.options.Options.MatcherStatus) |
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.
🛠️ Refactor suggestion
Refactor the workaround for handling unmatched events
The current implementation includes a workaround to handle cases where the callback is not called and matcher-status
is true, as indicated by the TODO comment. This approach may lead to maintenance challenges and unexpected behaviors.
Consider refactoring this section to wait for the ScanContext
to complete before proceeding. This would ensure proper synchronization and more robust handling of unmatched events.
Would you like assistance in proposing a refactored implementation for this section?
Hi @babariviere, this should come with a detailed issue report providing clear steps to reproduce it to properly understood and addressed effectively. |
@dwisiswant0 It's really hard to reproduce since there is really small time frame between the Lock and Unlock. Maybe a time.Sleep in-between should do the trick but I have not yet tested it, and don't have the time. |
@dwisiswant0 have you checked the |
Proposed changes
The fix copy the lastMatcherEvent pointer to avoid a race condition where:
This result in an error like this:
Here is an example crash log:
crash.log
I don't think this should be the final fix. This should probably wait for the ScanContext to end/stop.
Checklist
Summary by CodeRabbit
New Features
Bug Fixes
Documentation