Troubleshoot Glade

Troubleshooting

Start with the symptom you recognize. Confirm project context before changing Apex source or local data.

Glade cannot find my project

Run this from the directory that contains sfdx-project.json. The block stops before initialization when the project file is missing.

(
  test -f sfdx-project.json || {
    printf '%s\n' 'No sfdx-project.json here. Move to your Salesforce DX project root, then retry.' >&2
    exit 1
  }
  if test ! -f glade.yml; then
    glade init --project . --yes || exit 1
  fi
  glade doctor --project . || exit 1
)

Initialization can create glade.yml. Inspect that file before committing it. A failure here does not establish that your Apex source is invalid. Continue with the first local check.

glade doctor fails

Read the first failed status row and its Fix: section.

• Project: pass the existing directory that owns sfdx-project.json or glade.yml.
• Config: run the printed glade init or glade config validate command, then correct the named file.
• Parser: reinstall a packaged release, or rebuild with CGO_ENABLED=1 and a C compiler.
• Local data: Apex remains ready. Run the printed glade db inspect --project ... advisory before DB-backed workflows to recheck the project's schema binding.
• LWC tools: this is an advisory for Apex check and test, but LWC compilation and Lightning runtime routes need it. Release users should reinstall the complete package. Source developers can run glade toolchain install --from path/to/glade from a Glade checkout.

Repeat the exact printed doctor command. Ready. means local Apex prerequisites passed; it does not prove that a test ran or that Salesforce was contacted.

A test is not discovered

Find a known test class in the active package directories listed by your project's configuration. Read its class declaration and test methods; do not use an entire suite merely as an inventory command.

From the project root, enter that class name when prompted:

(
  test -f sfdx-project.json || {
    printf '%s\n' 'Move to the Salesforce DX project root first.' >&2
    exit 1
  }
  printf 'Known test class name: '
  IFS= read -r test_class || exit 1
  case "$test_class" in
    ''|*[!A-Za-z0-9_.]*)
      printf '%s\n' 'Enter a nonempty class name, without spaces or angle brackets.' >&2
      exit 1 ;;
  esac
  glade test --project . --class "$test_class"
)

This command executes the selected class. Check the executed-test count, not just the exit status. When you need to separate installation from your project's behavior, use the small first-run sample.

For a bug report, record the exact selected name, Glade version, expected test count, and actual count. Share only source and diagnostics you are authorized to publish. Security reports use the existing private route.

Test server refuses to connect after an upgrade

The persistent test server uses daemon protocol 3. Stop a server started by an older binary before upgrading, then restart it with the new binary:

glade test daemon stop --project .
glade test serve --project .

If the new client reports a protocol mismatch, stop the old foreground server with Ctrl-C (or use its original binary's stop command), then start the new server. A newer client's stop command may only remove stale socket/PID files when it cannot speak the old protocol; that does not prove the old process exited.

Test results changed time zone

The default local running user uses America/Los_Angeles. Check expectations that assume UTC for Datetime.format() or local date components. Use GMT methods when that is the intended contract, or set TimeZoneSidKey explicitly on a test user and run the code inside System.runAs.

Local and Salesforce results differ

Record the exact Glade command and result, then check the capability in What runs locally. Hosted services and exact production behavior remain Salesforce validation. Report a reproducible mismatch with the smallest source, metadata, and data fixture that shows it.

VS Code cannot find the Glade binary

Run glade editor doctor vscode in a terminal where glade version succeeds. Restart VS Code after changing PATH. See Use Glade in VS Code.

A breakpoint is not hit

First prove the selected test runs locally. Then confirm the launch points at the same project and class. Follow Debug Apex with breakpoints.

A local sf target is missing

Start and authorize the named local target again. The isolated-shell and cleanup rules are in Set up a Glade org and import data with sf.

A plugin is not restored in CI

Commit the plugin lock file, use the same Glade version locally and in CI, and follow Plugin lock files and CI. Plugins are separate executables; a base Glade install does not restore them implicitly.

A test command exits zero but runs no tests

Read the JSON summary.total and the selected method names. Confirm the class and method exist in the active package directories. An empty changed-test selection can be legitimate; run a known relevant class or suite to establish execution evidence. Use the first-run sample when diagnosing installation separately from project behavior.

Verify recovery

Repeat the exact command that failed in the same project and local environment. Check its diagnostic and executed-test counts as well as its exit code.

Still blocked

Include glade version, glade doctor --project ., the exact command, stable error code, and the smallest reproducible project state in a GitHub issue. Remove credentials, private source, and customer records first. Vulnerabilities use private reporting.