-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Flashpoint ignite - is_time_sensitive() related changes #38862
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
Flashpoint ignite - is_time_sensitive() related changes #38862
Conversation
Your contributed Flashpoint pack has been modified on files:Packs/Flashpoint/pack_metadata.json |
The following errors were thrown as a part of this pr: ST111. |
This PR is marked as 'Stale' because it has been open for 30 days with no activity, it will be automatically closed in 15 days if no activity will be done. To reset the counter just remove the 'Stale' label or make changes to update this PR. If you wish this PR will never be marked as 'Stale' add the 'Ignore Stale' |
This PR is marked as 'Stale' because it has been open for 30 days with no activity, it will be automatically closed in 15 days if no activity will be done. To reset the counter just remove the 'Stale' label or make changes to update this PR. If you wish this PR will never be marked as 'Stale' add the 'Ignore Stale' |
Hello, this is Luke from Flashpoint. We've tested this change and it functions correctly and as expected. Thank you for your patience as we've been working through this. On the technical side we have been discussing and we do have a concern that even a small network hiccup would cause the enrichment command to fail and harm the experience for customers. We'd like to suggest changing the 10 seconds to 15, and changing the 0 retries to 2 (the first retry happens instantly). Considering the feedback from yourselves and the customer, we agree that the current retry method is too heavy for enrichment purposes, but having no retries feels like a risk as well. If your team is okay with 15s and 2 retries, we can agree to this change immediately. Additionally when we make these changes, we can also observe by how much this particular customers' timing is improved and discuss if we need to further reduce the timing or restrategize. What are your thoughts? |
Hi @LHousehold , Thanks for the update and for validating the fix. I’ll increase the timeout to 15 seconds as suggested. However, regarding the retry count, we believe it's best to keep it at 0. During enrichment, minimizing the number of calls is critical to ensure optimal performance—additional retries could significantly degrade the user experience. Let me know your thoughts. Best regards, |
Coverage Report
|
Validate summary Verdict: PR can be force merged from validate perspective? ✅ |
@yuvalbenshalom - Please force merge the PR. |
* lowered retries and timeout when is_time_sensitive is True * Added RN * fixed typo * Updated the docker image * Added a comment * Increase timeout on enrichment to 15 sec * Added RN * revert change in old RN file * Updated the docker image tag * pre commit fixes * ruff fixes
* lowered retries and timeout when is_time_sensitive is True * Added RN * fixed typo * Updated the docker image * Added a comment * Increase timeout on enrichment to 15 sec * Added RN * revert change in old RN file * Updated the docker image tag * pre commit fixes * ruff fixes
* lowered retries and timeout when is_time_sensitive is True * Added RN * fixed typo * Updated the docker image * Added a comment * Increase timeout on enrichment to 15 sec * Added RN * revert change in old RN file * Updated the docker image tag * pre commit fixes * ruff fixes
Contributing to Cortex XSOAR Content
Make sure to register your contribution by filling the contribution registration form
The Pull Request will be reviewed only after the contribution registration form is filled.
Status
Related Issues
relates: CIAC-12908
Description
Must have