We are currently in the process of adopting Forge triggers to migrate from our Connect webhooks, and we are running into a recurring pattern:
- data that was readily available in Atlassian Connect event payloads is often missing or incomplete in Forge events.
- lack of feature-parity with filter options that increase the volume of events we have to process
To bridge this gap, we are forced to implement workarounds that involve additional API calls to the product to fetch the required context.
Some specific examples of where we are facing this include:
- Additional event volume: Lack of entity property filter options forces us to handle more requests and bloat additional API request volume (see ECO-1059).
- Missing data in triggers: We have to fetch entity properties manually because they aren’t included in the event payload (see FRGE-1801).
- Missing data in invocation context: We have to fetch the server info API for each Forge Remote request manually to retrieve the host base URL (see FRGE-1961).
- Redundant events: Issues like the assigned trigger firing double bloats the event volume (workaround available but default behavior highly unintuitive (see Why does the issue assigned trigger double the event volume?).
Atlassian has stated:
However, I do not think that this assessment includes the API bloat described in the examples above. Our current numbers do not account for the significant multiplier in API requests we are about to implement solely to work around these shortcomings.
My questions for Atlassian:
- Is there a roadmap to close these gaps so we can keep our API footprint at Connect-like levels before the new rate limits and the Forge penalty kick in?
- How can we trust the assessment that apps do not experience any impact with the new rate limits, when that data doesn’t account for the extra load required to work around Forge limitations?
I’m worried the real-world impact is being underestimated.
