Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A Jira issue returning 404—or disappearing from search—does not necessarily mean it was deleted. In a single Jira Cloud test, a Forge app saw those responses when organization policy blocked its access, while the user could still read the issue. Before treating the data as gone, check the project’s policy metadata and handle blocked-content events safely.
Why a 404 or empty search can be misleading
In a test run on 2026-09-28, Mihai Perdum used Forge CLI 12.21.0 and @forge/api 8.1.0 on a personal Jira Cloud test site. When app access to an issue was blocked, the app’s issue read returned HTTP 404 with the generic message “Issue does not exist or you do not have permission to see it.” A JQL search returned HTTP 200 with an empty issues array. The project remained readable, and the author could read the issue as a user.
These are observations from one site and one test, not proof that every Jira Cloud app will always receive identical responses. They do show why an app should not treat a 404 as definitive deletion or an empty search as proof that no matching content exists.
Check project policy metadata before interpreting missing results
The report found that /rest/api/3/data-policy/project?ids=<projectId> remained available and returned anyContentBlocked: true for the blocked project. The practical sequence is to identify the project associated with the issue or search, query that endpoint, and inspect its project-level anyContentBlocked value before deciding what the missing result means.
#1 Best Overall
- Issue read returns 404: if the project is known, query
/rest/api/3/data-policy/project?ids=<projectId>and inspect the project’sanyContentBlockedvalue. - Search returns no issues: consider whether policy could have hidden content from the app, and check policy state for the relevant project or projects rather than assuming the result is complete.
- Choose a safe app response: when the policy signal indicates blocked content, avoid marking cached records as deleted or removing user data solely because the app can no longer retrieve it.
This endpoint and behavior are reported by the field test; verify current Jira documentation and app permissions for the deployment you support before relying on the path or response shape.
Use each blocked event for the right purpose
The report names two blocked event types. They provide different levels of detail, so subscribe according to what the app needs to know:
| Event type | What the report says it identifies | Useful for |
|---|---|---|
avi:ecosystem.app_policy:blocked:app_access_to_objects.v2 |
Blocked objects | Identifying affected issues or other individual objects in the event payload. |
avi:ecosystem.app_policy:blocked:app_access_to_objects_in_container.v2 |
The affected project container | Recognizing project-level impact. Do not infer from this event alone that every object in the project is blocked. |
In the logged sample, the author counted 36 deliveries of each event type. That is a count from one probe run, not an expected delivery rate or a typical volume.
Make event processing safe to repeat
The test observed container events delivered more than once with different event IDs but matching type, data, and time. Because duplicate delivery was observed only in this single test, it does not establish how often duplicates occur generally. Still, event handlers should tolerate repetition: make side effects idempotent, and deduplicate where appropriate using event type, payload data, and time rather than relying only on the event ID.
Keep the object and container signals distinct in your processing. Use object-level events when individual records need action; use a container event to flag project impact or trigger a policy-state check, not to manufacture a list of affected issues.
Detect blocks already in place and later access changes
The author reported no blocked event when installing the app while a block was already active, and no event when a block was removed. An event-only design could therefore miss both the initial blocked state and a later return of access in the reported scenario.
- At app startup, check policy state for projects the app needs to handle, rather than assuming installation events describe existing blocks.
- When the app needs to learn whether access has returned, recheck policy state for affected projects; the test did not observe an unblock event.
What this test does not establish
The behavior above should be read as a practical pattern based on one Jira Cloud test, not a universal contract. The report did not establish site-level flag behavior, a general policy-deletion procedure, Confluence behavior, event splitting thresholds, or whether a container policy can be published by itself. It also recorded an unexplained discrepancy: after the tested container block was removed, the site-level /rest/api/3/data-policy flag remained true while the project-level value changed to false. One deletion request returned HTTP 202 without removing the tested policies, while a versioned policy-delete call restored access; the report does not establish a general explanation or reusable deletion method.
For user-facing explanations of partial results, make clear that an organization policy may limit what the app can see. Confirm exact wording and current behavior in Atlassian’s developer documentation before presenting it as a platform guarantee.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
