feat: add version & build metadata to Pylon support chat

[salevine]

Description

Adds version and build metadata to the Pylon support-chat integration so support can immediately see which release/build a customer is on, on tickets created from every Pylon entry point.

Four new custom fields are attached to new Pylon issues:

Pylon custom-field slug	Value	Source
appsmith_edition	CE / EE	appVersion.edition
build_sha	git commit SHA	appVersion.sha
build_date	release date	appVersion.releaseDate
deployment_type	cloud / self-hosted	cloudHosting

Values come from getAppsmithConfigs(). The pre-existing appsmith_version, instance_id, and license_id fields are unchanged. account_external_id remains intentionally omitted to preserve Pylon email_hash identity verification.

How it works (covers all entry points)

The fields are set via a shared setPylonNewIssueCustomFields() helper in app/client/src/utils/bootPylon.ts, called from two places:

1. At SDK boot — via a load-event handler on the injected Pylon script (bootPylon). Every chat-capable surface calls bootPylon before chat can be shown, so this covers issues created from the debugger contextual menu, repo-limit modal, homepage search, onboarding help menu, and datasource auth error — which previously carried no metadata.
2. On the Help-menu path (updatePylonChatIdentity) — additionally includes instance_id, which is only available there.

instance_id is cached module-side so a later boot-time call still carries it — the value cannot be dropped regardless of whether Pylon merges or replaces custom fields across calls.

⚠️ Required Pylon dashboard setup

These new field slugs must be created in the Pylon workspace (exact slugs, not labels) or Pylon silently drops the values — no client-side error:

• appsmith_edition
• build_sha
• build_date
• deployment_type

(appsmith_version, instance_id, license_id already exist.) The code is safe to merge independently but is inert until the slugs exist in Pylon.

Type of change

• New feature (non-breaking, additive, no feature flag)

How Has This Been Tested?

• yarn run check-types → pass (exit 0)
• yarn eslint src/utils/bootPylon.ts → pass (exit 0)
• Manual verification of the payload sent to Pylon is pending in a Pylon-configured environment (REACT_APP_PYLON_APP_ID set, authenticated user): open chat from multiple entry points and inspect the setNewIssueCustomFields payload / chatwidget/issue request; confirm email_hash identity still verifies (no 401).

Reviewer notes

• Client-only, single file (bootPylon.ts). Both changed helpers (injectPylonScriptOnce, setPylonNewIssueCustomFields) are module-private; exported signatures are unchanged.
• No secrets/PII added — commit SHA is public (OSS); identity flow untouched. license_id now reaches Pylon at SDK boot for verified users (Pylon is already trusted with email_hash); flagged as a data-minimization consideration, not a blocker.

🤖 Generated with Claude Code

Automation

/ok-to-test tags="@tag.All"

Tip

🟢 🟢 🟢 All cypress tests have passed! 🎉 🎉 🎉
Workflow run: https://github.com/appsmithorg/appsmith/actions/runs/29098954808
Commit: a5c77c2
Cypress dashboard.
Tags: @tag.All
Spec:

---

Fri, 10 Jul 2026 15:30:05 UTC

[coderabbitai]

Walkthrough

The updatePylonChatIdentity function in bootPylon.ts now passes additional custom fields (appsmith_edition, build_sha, build_date, deployment_type) to setNewIssueCustomFields, derived from appVersion and cloudHosting. Inline documentation explains field naming requirements.

Changes

Pylon Chat Identity Fields

Layer / File(s)	Summary
Extend custom fields payload app/client/src/utils/bootPylon.ts	Adds appsmith_edition, build_sha, build_date, and deployment_type to the setNewIssueCustomFields call, derived from appVersion/cloudHosting, with added inline docs on Pylon slug naming.

Estimated code review effort: 1 (Trivial) | ~3 minutes

Poem

A rabbit hops through Pylon's gate,
Adding fields to seal the fate—
Edition, sha, and build date true,
Deployment type comes shining through 🐇
Small diff, big clarity for the crew.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly summarizes the Pylon metadata addition and matches the change set.
Description check	✅ Passed	The description covers scope, motivation, implementation, and testing, with only minor template omissions like the issue reference and communication checkbox.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/add_data_for_pylon

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

This PR has not seen activitiy for a while. It will be closed in 7 days unless further activity is detected.