v0.7.31: sidebar shortcut, env var expansion in lifecycle triggers, ashby fixes#5622
Conversation
* feat(sidebar): add Cmd+B shortcut to toggle sidebar collapse * fix(sidebar): skip Cmd+B sidebar toggle inside editable fields * fix(sidebar): don't dead-zone Cmd+B on read-only editors; drop stale Mod+B ownership * chore(lint): apply biome fixes
…scription creation (#5619) * fix(webhooks): resolve env var references before deploy-triggered subscription creation Provider config fields like an API key can reference an environment variable via {{VAR_NAME}}. The interactive trigger-save route already resolved these before calling a provider's createSubscription, but the async deployment-outbox path (workflow deploy -> saveTriggerWebhooksForDeploy -> createExternalWebhookSubscription) did not, so the literal unresolved {{VAR_NAME}} string was sent to the provider as the credential and rejected. Resolve env vars in createExternalWebhookSubscription itself so both callers behave the same; the persisted providerConfig keeps storing the unresolved template, only the outbound call gets the resolved value. * fix(webhooks): guard against a non-string workspaceId when resolving env vars workflow.workspaceId as string | undefined was an unchecked cast on a Record<string, unknown> — if a caller ever passed a workflow-like object where workspaceId isn't actually a string, workspace-scoped {{VAR}} references would silently stay unresolved and the provider would receive the literal template as the credential, reproducing the exact class of bug this change exists to fix. Replaced with a runtime typeof check that falls back to undefined (personal-env-only resolution) instead of forwarding an unvalidated value.
… before dispatch (#5621) * fix(ashby): parse alternateEmailAddresses and socialLinks into arrays before dispatch The Ashby create_candidate and update_candidate tools require alternateEmailAddresses (string[]) and socialLinks ({type,url}[]) as JSON arrays in the request body, guarded by Array.isArray checks. The block collected both through long-input text fields but forwarded the raw string straight through to tools.config.params, so Array.isArray was always false and both fields were silently dropped on every create/update call. Parse them in tools.config.params (execution-time, after variable resolution) using the same comma-separated-or-JSON-array pattern used elsewhere in the codebase (see blocks/findymail.ts), and add wandConfig to both fields so the AI wand can generate well-formed input for them. * fix(ashby): drop json-object generationType from array-shaped wandConfig fields generationType: 'json-object' makes the wand API append an instruction that the response must start with { and end with }, but alternateEmailAddresses/socialLinks parse a raw JSON array or comma-separated string, not an object. A wand-generated {"emails":[...]}-shaped response would get comma-split into invalid email fragments by parseStringListInput, and an object-wrapped socialLinks response would get silently dropped by parseSocialLinksInput returning []. Matches the existing array-field wandConfig pattern in blocks/findymail.ts, which never sets generationType and relies on the prompt text alone. * fix(ashby): remove the non-functional candidateId filter from list_applications Live-verified against Ashby's application.list endpoint: passing candidateId (including a nonexistent UUID) returns identical, unfiltered results either way — Ashby's API silently ignores this body field entirely. Sending it gave users the false impression of filtering by candidate while actually returning every application. Removed the param, the tool type, and the block's filterCandidateId subBlock/wiring/input. The correct path for a candidate's applications is ashby_get_candidate's applicationIds field. * fix(ashby): add subblock-id migration for the removed filterCandidateId field The subblock ID stability CI check correctly caught that removing filterCandidateId without a migration entry would silently drop the value on already-deployed workflows. Added the standard _removed_ mapping, following the same pattern already used for this block's prior removals (emailType, phoneType, expandApplicationFormDefinition, expandSurveyFormDefinitions).
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
PR SummaryMedium Risk Overview Global commands now use Webhook deploy/lifecycle registration resolves Ashby block parses
Reviewed by Cursor Bugbot for commit 5dec4f3. Configure here. |
Greptile SummaryThis PR updates shortcuts, webhook subscription setup, and Ashby block inputs. The main changes are:
Confidence Score: 5/5This looks safe to merge after small input-handling cleanups.
apps/sim/app/workspace/[workspaceId]/providers/global-commands-provider.tsx; apps/sim/blocks/blocks/ashby.ts Important Files Changed
Reviews (1): Last reviewed commit: "fix(ashby): parse alternateEmailAddresse..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| return Array.isArray(parsed) ? parsed : [] | ||
| } catch { |
There was a problem hiding this comment.
When the wand or a user enters social links as a non-JSON string, this parser returns an empty array and the params builder omits socialLinks entirely. The Ashby update can then complete without applying the requested social links, with no error shown to the workflow author.
There was a problem hiding this comment.
Confirmed real — good catch. Traced it: parseSocialLinksInput returns [] on any non-JSON-parseable input, and tools.config.params only sets result.socialLinks when the parsed array is non-empty, so malformed input silently omits the field and the Ashby update 'succeeds' without applying the requested links. Fixed in #5624 (throws a clear error instead, matching the existing throw-on-invalid-JSON pattern in blocks/airtable.ts) rather than fixing it here directly since this is the staging→main release PR, not the feature branch.
…5623) * fix(global-commands): use isContentEditable for the editable guard * chore(lint): keep focusable span in editable-guard test with biome-ignore
…Links (#5624) * fix(ashby): fail loudly instead of silently dropping malformed socialLinks parseSocialLinksInput returned [] for any non-JSON-parseable input, and tools.config.params only sets result.socialLinks when the parsed array is non-empty — so a malformed socialLinks string (user typo, or a wand response that didn't follow the JSON-array prompt) silently omitted the field entirely. The Ashby candidate.update call then succeeded without applying the requested links, with no error surfaced to the workflow author. Throw a clear error instead, matching the existing throw-on-invalid-JSON pattern used elsewhere (e.g. blocks/airtable.ts). * fix(ashby): use getErrorMessage instead of inline error-message extraction check:utils bans the e instanceof Error ? e.message : fallback pattern in favor of getErrorMessage(e, fallback?) from @sim/utils/errors.
1 participant
Uh oh!
There was an error while loading. Please reload this page.