fix(ashby): parse alternateEmailAddresses and socialLinks into arrays before dispatch#5621
Conversation
… 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.
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
PR SummaryLow Risk Overview The block now normalizes those values in
Reviewed by Cursor Bugbot for commit 78d47f7. Configure here. |
Greptile SummaryThis PR fixes Ashby block handling for array-shaped candidate fields. The main changes are:
Confidence Score: 5/5This looks safe to merge.
Important Files Changed
Reviews (4): Last reviewed commit: "fix(ashby): add subblock-id migration fo..." | Re-trigger Greptile |
…fig 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.
|
Confirmed and fixed — pushed |
|
@cursor review |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 92cfb95. Configure here.
…plications 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.
|
Pushed one more fix ( |
|
@cursor review |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 7f70458. Configure here.
…Id 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).
|
Fixed the CI failure — the Subblock ID stability check correctly caught that removing |
|
@cursor review |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 78d47f7. Configure here.
Summary
create_candidate'salternateEmailAddressesandupdate_candidate'ssocialLinksare guarded withArray.isArray(...)in the tool layer (per Ashby'scandidate.create/candidate.updatedocs, both are JSON arrays), but the block only ever collected them via along-inputtext field and forwarded the raw string straight through — soArray.isArraywas always false and both fields were silently dropped on every call, regardless of what the user typed.tools.config.params(execution-time, after variable resolution — never intools.config.tool, which would destroy<Block.output>references) using the same comma-separated-or-JSON-array pattern already used elsewhere (blocks/findymail.ts). AddedwandConfigto both fields so the AI wand can generate well-formed input.Type of Change
Testing
apps/sim/blocks/blocks/ashby.test.ts: comma-separated parsing, JSON-array parsing, empty-input omission, malformed-JSON omission (5 tests, all passing).bunx vitest run blocks/ tools/ashby/— 278+ tests passing.bunx turbo run type-check --filter=sim --force— clean (one pre-existing, unrelatedproviders/meta/index.tserror confirmed identical on unmodified staging).bunx biome checkon touched files — clean.Checklist