Fix "Risk Meeting" dashboard data fetches from extension

[NKoech123]

Summary

The Risk Meeting dashboard was migrated from Fusion Analytics to Agent-Native as an Alpine SQL extension, but it could not reliably load enriched HubSpot and Pylon cohorts. HubSpot flagged deals often returned 0 or timed out; Pylon early-warning accounts failed to fetch or returned the wrong count.

This PR adds generic, caller-configured actions for the same join pattern Fusion used, fixes extension/action timeouts that were cutting requests off early, and corrects secondary-cohort join logic so HubSpot + Pylon counts match production (~43 flagged HubSpot deals + ~21 Pylon-only accounts).

The Risk Meeting UI itself stays in SQL (extensions table). This branch only ships the server/action surface the extension calls.

Problem

After migration, the dashboard hit several independent failures:

1. No generic data path — Fusion had bespoke orchestration; Analytics needed reusable actions the extension could call with property bindings (deal status field, segment, Pylon sentiment fields, join keys).
2. HubSpot cohort gap — hubspot-deals could not do CRM property IN search; extensions fell back to slow full-catalog scans or keyword search with incomplete results.
3. Timeouts stacked against us — Extension iframe bridge defaulted to 30s; the SQL extension also wrapped appAction() in client-side withTimeout (28s / 8s), so longer server actions (hubspot-deals 90s, build-secondary-cohort 360s) never finished.
4. Pylon fetch/join bugs — Name-based account search missed custom-field sentiment; sentiment-filtered maps broke join lookups; secondary cohort excluded the wrong HubSpot deals (bounded CRM page vs full scan), inflating Pylon counts (e.g. 76 vs 21).

Solution

Generic actions (extension owns bindings)

Action | Role -- | -- hubspot-deals | CRM IN search via propertyValues + dealProperty; adds csm_name enrichment build-secondary-cohort | Pylon↔HubSpot join with caller-supplied property names; excludes accounts already flagged in CRM pylon-accounts | Bounded raw Pylon fetch by sentiment field/values

Server libs

• HubSpot — searchHubSpotDealsByPropertyValues, batch association reads, customer_success_owner on default deal properties
• Pylon — structured /accounts/search, 429 retry, custom-field parsing, full sentiment map for join lookups
• secondary-cohort — config-driven join: enterprise segment filter, future close-date rollups, scan all HubSpot deals for primary-property exclusions

Framework

• Extension bridge (html-shell.ts) — hostRequest/appAction honor callOptions.timeoutMs; raised defaults for slow read-only actions

Docs / cleanup

• AGENTS.md — documents multi-source HubSpot + Pylon pattern
• Removed repo-only artifacts: extension HTML paste file, example seed JSON, deprecated riskStatuses/statusProperty aliases

Test plan

•  Open Risk Meeting dashboard (SQL extension) with HubSpot + Pylon credentials configured
•  HubSpot tab loads ~43 flagged accounts via propertyValues/dealProperty CRM search (no 28s client timeout)
•  Pylon tab loads ~21 early-warning accounts after build-secondary-cohort completes (allow 1–2 min on cold load)
•  Reload dashboard — counts stay stable (no flapping 43→0 on HubSpot)
•  pnpm test hubspot-deals.spec.ts in templates/analytics
•  Re-paste updated extension HTML into SQL if it still uses withTimeout / 28s wrappers (not in this PR)

Notes

• Extension content is not in the repo; update the live SQL extension separately if it still has client-side timeout wrappers.
• html-shell.ts still has analytics action names in EXTENSION_ACTION_TIMEOUT_MS — follow-up to make this fully generic or rely only on callOptions.timeoutMs.

---

[builder-io-integration]

Builder reviewed your changes and found 5 potential issues 🟡

Review Details

This PR migrates the Risk Meeting dashboard’s data-loading path to generic Analytics actions: a faster HubSpot property-based deal search, a new generic Pylon account action, and a secondary-cohort join that combines Pylon sentiment with HubSpot deals. It also raises iframe bridge timeouts so slower read-only extension actions can complete instead of failing at the default 30s limit.

The overall direction is sound: keeping the extension-specific binding JSON outside the actions is a good abstraction, and the timeout changes are appropriately scoped to known slow actions. Risk level is standard because this touches shared provider fetch/caching logic plus user-facing dashboard data paths.

Key findings:

• 🟡 Secondary cohort result caching does not key on all caller-supplied bindings, so different dashboard configs can reuse the wrong cached cohort.
• 🟡 The deal→company join currently depends on association array order, which can mis-join multi-company deals.
• 🟡 New provider search/cache helpers have a few correctness gaps around response-shape caching and multi-page/filter aggregation.

Good additions here include targeted HubSpot CRM search coverage and clearer guidance/docs for the new generic actions.

🧪 Browser testing: Will run after this review (PR touches UI code)

[steve8708]

can the agent not access pylon APIs directly using fetch()? my hope is to remove hard coded actions as much as possible and make sure the agent can just have broad access to pylon/hubspot/etc's APIs and docs like claude code etc would o. would generally prefer to remove vendor-specific actions rather than make more

[github-actions]

Here's a visual recap of what changed:

Open the full interactive recap

[builder-io-integration]

Builder reviewed your changes and found 3 potential issues 🟡

Review Details

This incremental update trims the earlier Pylon helper surface, keeps the new generic secondary-cohort action, and retains the HubSpot property-value search plus iframe timeout changes for extension actions. The direction is still reasonable overall, and I verified that two previously reported Pylon issues are no longer applicable on this revision and have been resolved rather than reposted.

Risk level remains standard because this still changes shared provider-fetch logic plus user-facing analytics/dashboard data loading. The previously-open concerns around secondary cohort caching, deal→company association selection, and HubSpot property-search cache shape are still present, so I did not duplicate them here.

New findings from this revision:

• 🟡 Risk-sentiment matching is still case-sensitive against caller-supplied config values, which can silently empty or shrink the secondary cohort.
• 🟡 The new propertyValues fast path in hubspot-deals bypasses the action’s normal pipeline/status/date/owner filtering, so combined cohort requests can return broader results than requested.
• 🟡 buildSecondaryCohort() assumes an exhaustive deal scan, but it currently relies on a helper explicitly capped at 10k HubSpot deals.

The timeout plumbing itself still looks sound.

🧪 Browser testing: Will run after this review (PR touches UI code)

[steve8708]

@NKoech123 i'm going to get a PR in shortly that I think may help get the foundation a little closer to what I think the ideal state is re: making sure our requests to various services works well in general. will lyk once it's in and maybe I can get your help testing some stuff out

[NKoech123]

@NKoech123 i'm going to get a PR in shortly that I think may help get the foundation a little closer to what I think the ideal state is re: making sure our requests to various services works well in general. will lyk once it's in and maybe I can get your help testing some stuff out

Thanks @steve8708 . What do you think about the current changes? Introduced searching hubsport with generic propertyValues

[steve8708]

just got the big changes in - i'd prefer we try to make data programs work for this stuff - basically reduce as much as possible provider-specific actions and have the agent instead do more directh requests to the various providers APIs (without us adding arbitrary wrappers that will always have constraints and need tweaking)

@NKoech123 can you try this out and see if hubspot provider tweaks is still needed? I can see value in the extension timeout stuff, but want to see if we can solve the root problem more when it comes to agent accessing hubspot, pylon, etc info better