Improve webhook event data
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
Research direction
Start by tracing the IncidentCreated event from the API action and the dashboard incident-creation flow, especially when incident components are attached. Check how webhook payloads are assembled and verify that incident events include affected components without dispatching before those components exist. Done means both creation paths produce complete webhook data.
Written by the indexing model from the issue text.
Description
Webhooks need to include additional data. For example, incidents should include a list of affected components.
This is easily doable within the API (since we can refactor the action to dispatch the event) but creating incidents via the dashboard will prematurely fire the IncidentCreated event before the incident components are attached.
- Dominant language
- PHP
- Stars
- 230
- Forks
- 83
- Avg merge
- 12h 42m
- Merged PRs (30d)
- 5
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from cachethq/core
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Banner image upload fails with "The banner image field contains a file path that is not permitted"Open
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
Similar issues
-
Security SecurityBundle
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
symfony/symfony-docs#23173 ·
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
fossology/fossology#3893 · 1 comment ·
Maintainers usually reply within 2 days
-
Documentation Feature: Self-Register / Verify UI
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
i18n
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
WordPress/wordpress.org#1002 ·
Maintainers usually reply within 4 days
-
Bug
Difficulty 1/5 Under an hour Newbie friendliness 90/100
Maintainers usually reply within 1 day