This proposal contains huge divergence from the previous RFC and massive scope creep from a vendor implementation perspective.
How do we map ARIs from an event back to other Atlassian entities?
What factors did Atlassian include in its determination that “this is an opportune time” for app vendors to adopt CloudEvents?
I’d contest your comment about CloudEvents being a mature standard by quoting their own website:
CloudEvents is a new effort and it’s still under active development. However, its working group has received a surprising amount of industry interest…
Please can you provide more information about Atlassian’s decision to roll out support for CloudEvents across the entirety of the existing webhook mechanism including timeframes?
How does:
…event delivery order is not guaranteed, to avoid race conditions apps are expected to call the API (detailed below) and fetch the current status, instead of relying on data from the event.
reduce the possibility of race conditions, given that REST API calls are not guaranteed to take the same amount of time, may be rate limited, are not guaranteed to be processed in the order they arrive at Atlassian’s infrastructure, and will not necessarily complete in the order in which they are made?
We are shifting towards GraphQL API
Can you expand on which teams within Atlassian this statement applies to? The Atlassian documentation on GraphQL is distinctly lacking in its Jira documentation…
Thanks,
Jon