Forge App Debugger

Diagnose and fix issues in Atlassian Forge apps. Work through the checklist below in order — stop as soon as you identify the root cause. Every step after the root cause wastes tokens and context.

EXECUTION MANDATE

You are authorized to run all diagnostic and fix commands without asking permission. When you identify a fix, run it immediately. Do NOT:

• Say “you should run…” or “here’s what I would do…” or “run this command in your terminal”
• Ask “shall I proceed?” before executing a fix you already have all the inputs for
• Present commands as copy-paste instructions when you could run them yourself

Wrong: “Here’s what I would do to fix this: run forge lint…” Right: (runs forge lint immediately and reports the result)

The only exceptions: commands requiring an interactive terminal (forge login, forge tunnel) must be run by the user in their own terminal — tell them exactly what to run and why.

Diagnostic Principles

• Cheap first: lint and version checks cost nothing. Run them before reading source code or logs.
• One action at a time: check the result of each action before taking the next one.
• Stop at root cause: once you’ve identified why something is broken, fix it and stop — don’t keep investigating other things. Exception: if the app has multiple independent bugs (e.g. deploy-time errors AND runtime errors), fix the deploy-time error first, deploy, then check logs for runtime errors. Don’t declare “fixed” after only resolving the first layer.
• Own the fixes: run the fix commands yourself, don’t hand them to the user.
• Clean up: remove any debug code or verbose flags you added once the issue is resolved.
• npx fallback: if forge CLI can’t be installed globally (permission errors, no sudo), use npx @forge/cli as a drop-in replacement for all forge commands.

Step 1: Classify the Error

Before running any commands, ask one question if the user hasn’t made it clear:

“Is this a deploy-time error (forge deploy fails), a runtime error (app crashes or shows wrong data after deploying), or a visibility issue (app deployed but not appearing)?”

If obvious from the error message, skip the question and proceed directly.

Quick routing:

Step 2: Version Check

forge --version
npm show @forge/cli version

If the installed version is behind the latest major version, upgrade immediately:

npm install -g @forge/cli

Then retry the failing operation. Many bugs are fixed in newer CLI versions.

Step 3: Lint

forge lint

Fix every error before proceeding — lint errors cause deploy failures and silent runtime bugs. If lint passes cleanly, continue to the next step.

For any manifest-related error message (e.g. “invalid manifest”, “unexpected key”, “modules.jira:*” errors): run forge lint first before reading any source files. Lint will identify the exact line and field causing the problem — reading the file before linting is wasteful and usually less informative than the lint output.

Step 4: Custom UI Build Check

Only applies when the app has a static/ directory (Custom UI apps). Check if the frontend was built before the last deploy:

ls -la static/build/

If the build directory is missing or older than recent source changes, rebuild:

cd static && npm run build && cd ..

Then redeploy:

forge deploy -e development

This is one of the most common causes of blank UI panels.

Step 5: Deploy Status

Verify the app was actually deployed successfully:

forge deploy -e development --verbose

Watch for errors in the output. Note the deploy timestamp. If deploy fails, the error message usually identifies the problem directly — match it against the Common Error Patterns table below.

Step 6: Logs

forge logs -e development --limit 100

Read the logs carefully. Most runtime errors appear here.

If no logs are returned

The resolver may not have been triggered, or logging isn’t set up. Add a debug log at the entry point of the resolver:

// Add at the top of your handler function:
console.error('[DEBUG] Handler called with:', JSON.stringify(payload));

Then redeploy and trigger the app again:

forge deploy -e development
forge logs -e development --limit 100

Remove the debug log after you’ve identified the issue.

If the error is in the frontend (UI rendering, blank screen)

Forge UI Kit errors surface in forge logs, not the browser console. For Custom UI, add error logging in the resolver that backs the UI:

try {
  const result = await api.asUser().requestJira(/* ... */);
  return result;
} catch (err) {
  console.error('[DEBUG] Resolver error:', err.message, err.stack);
  throw err;
}

Redeploy, trigger, and check logs.

Step 7: Production Issues

If the user reports an issue that only happens in production (or on a specific customer’s site):

1. Ask: “Which Atlassian site is affected? (e.g. customername.atlassian.net)”
2. Check production logs:

   forge logs -e production --site <customer-site> --limit 100
   

3. Note: production logs may be delayed up to 2 minutes after the event.
4. If the issue is permission-related, check whether scopes were upgraded after a new install — production installs require explicit --upgrade.

Common Error Patterns

Match the error against this table first. If you find a match, apply the fix directly without further investigation.

Handler Path Resolution

The handler field in manifest.yml has the format <path>.<export>, where:

• <path> is the file path relative to src/ (without src/ prefix, without file extension)
• <export> is the named export from that file

Examples:

Common mistakes:

• index.handler — wrong if the file is in a subdirectory like src/resolvers/
• src/resolvers/index.handler — wrong: bundler prefixes src/ automatically, resulting in src/src/resolvers/...
• resolvers/index.run — wrong if the file exports handler not run

Diagnostic trick: If forge lint reports “cannot find associated file” but you’re sure the file exists, try forge deploy --no-verify. The bundler error message shows the fully resolved path, which reveals whether the path is being doubled or misresolved.

Invoke Name vs Function Key

There are two separate name-matching requirements for UI Kit resolvers:

1. manifest.yml function.key must match the resolver: function: reference in the module definition
2. Frontend invoke('name') must exactly match resolver.define('name', ...) in the backend

These are independent — you can have the manifest function key correct but still get undefined results if the invoke name doesn’t match resolver.define. When debugging “resolver returns undefined” with no errors in logs, always check both matching relationships.

API Migration (v1 → v2)

Atlassian is progressively deprecating v1 REST API endpoints. When you see a 410 Gone response:

1. Check forge logs for the exact error — it will show which endpoint returned 410
2. Identify the v2 equivalent:
   • URL pattern: /wiki/rest/api/content/... → /wiki/api/v2/pages/... (or /blogposts/..., /spaces/...)
   • Jira: /rest/api/2/... → /rest/api/3/...
3. Update pagination: v2 Confluence APIs use cursor-based pagination (cursor parameter) instead of offset-based (start parameter). The next cursor is in data._links.next
4. Update response shape: v2 may return different field names (e.g. authorId instead of nested by.accountId)
5. Redeploy and check logs to confirm the fix

Do NOT treat 410 as a permissions issue — it means the endpoint no longer exists, not that access is denied.

Step 8: Cleanup

Once the issue is resolved:

1. Remove any console.error('[DEBUG] ...') statements you added.
2. Remove verbose flags from any scripts.
3. Run forge lint one final time to confirm clean state.
4. Redeploy if you modified code during debugging:

   forge deploy -e development
   

5. Confirm the fix works by triggering the app and checking that forge logs shows no new errors.

Escalation

If none of the above resolves the issue:

• Run forge logs -e development --verbose --limit 200 for extended output.
• Check the Forge changelog for known issues: search-forge-docs "known issues <error-text>"
• If the error is in a Forge platform API (not your code), note the traceId from the log output — this is what Atlassian support needs.

Authentication Errors

If any command fails with “not authenticated” or “run forge login”:

1. Tell the user to create an API token at https://id.atlassian.com/manage/api-tokens
2. Tell them to run forge login in their own terminal (not via the agent) — it will prompt for their email and the API token
3. Example message: “You need to log in. Create an API token at https://id.atlassian.com/manage/api-tokens, then run forge login in your terminal. Enter your Atlassian email and the token when prompted — do not paste the token here.”
4. After they confirm login, resume debugging from where you left off.

Token Efficiency Rules

Follow these to keep context usage low:

• Read forge logs before reading any source file — logs usually reveal the root cause without needing to inspect code.
• Read only the specific file implicated by the error. Match the error to its file:
  • npm ERR! missing script: build → check only package.json (scripts section)
  • invalid manifest / unexpected key → run forge lint first, then only the specific manifest field
  • Resolver not found → check only the function key in manifest.yml vs resolver.define() in the resolver file
  • 403 / permission denied → check only the scopes in manifest.yml
  • 410 Gone → check the API endpoint URL in the resolver file; don’t check scopes or manifest
  • cannot find associated file → check the handler path in manifest.yml and the file location; use --no-verify to see the bundler’s resolved path
  • invoke() returns undefined → check both the frontend invoke('name') AND backend resolver.define('name') — two files, but targeted reads
• Don’t read manifest.yml for npm/build errors — they are unrelated.
• Don’t re-read a file you’ve already read in this session unless it changed.
• Stop the diagnostic chain the moment you find a match in the Common Error Patterns table. Exception: when multiple independent bugs exist (e.g. deploy error + runtime error), fix the first, deploy, then check for the next.
• Don’t run forge deploy more than once per fix attempt without a clear reason.
• Use forge deploy --no-verify as a diagnostic step when lint blocks deploy but you suspect the lint error may be misleading. The bundler error message often reveals the true path resolution issue. Always fix the root cause afterward — don’t ship with --no-verify.