fix(datasource-zendesk): coerce id filter values to integers for PK lookups#331
Merged
Merged
Conversation
The agent parses Number values through `to_f`, so `id = N` / `id IN [...]` filters reach the datasource as floats (e.g. `123.0`). The PK-lookup short-circuit forwarded those to Zendesk's REST endpoints, so `/tickets/show_many?ids=123.0` was rejected -- the error body embeds a validation regex that then fails JSON parsing, surfacing as APIError/500 -- and the id-keyed result map missed even when the call succeeded. Normalise id values to Integer in `extract_id_lookup`, the single choke point shared by Ticket (fetch_tickets_by_ids) and User/Organization (find_one). Surfaced by the workflow fallback-inbox flow, which lists client records via `id IN [...]`; existing specs built condition trees with raw integers and never exercised the parser's float casting. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Integer(123.9) truncates to 123, so a fractional id filter would match an unrelated record instead of nothing. Only normalise values whose integer conversion equals the original; leave fractional floats as-is. Addresses PR review feedback. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Revert normalize_id to the minimal integral coercion. The fractional branch guarded an input the agent parser never produces (integer PKs yield integral floats via to_f), and its spec asserted an empty result that the real client would not return -- a fractional id still hits show_many and raises the same APIError this fix addresses. Keep only what is strictly necessary. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
bexchauveto
approved these changes
Jul 13, 2026
forest-bot
added a commit
that referenced
this pull request
Jul 15, 2026
## [1.35.3](v1.35.2...v1.35.3) (2026-07-15) ### Bug Fixes * **datasource-zendesk:** coerce id filter values to integers for PK lookups ([#331](#331)) ([1575509](1575509))
Member
|
🎉 This PR is included in version 1.35.3 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The agent parses
Numbervalues throughto_f, soid = N/id IN [...]filters reach the Zendesk datasource as floats (e.g.123.0). The PK-lookup short-circuit (extract_id_lookup) forwarded those straight to Zendesk's REST endpoints:GET /tickets/show_many?ids=123.0is rejected by Zendesk. Its error body embeds a validation regex whose backslashes are invalid JSON, so parsing the response also throws — surfacing as:{ 123 => ticket }) is looked up with a float key (123.0) → miss → records silently dropped.This was hit in real conditions by the workflow fallback-inbox flow, which lists client records via
id IN [recordId].Fix
Normalise id values to
Integerinextract_id_lookup— the single choke point shared byTicket(fetch_tickets_by_ids) andUser/Organization(find_one) — before any REST call. Handles float and numeric-string inputs, leaves non-coercible values untouched.Why existing tests missed it
The specs built condition trees with raw integers (
Leaf.new('id', 'in', [1, 2])), bypassing the agent parser and itsto_fcasting. Added regression specs that pass float ids through the datasource for both the TicketIN/EQUALpaths and the Userfind_onepath.Validation
245 examples, 0 failures(full Zendesk datasource suite), coverage 99.33%Scope note
The underlying
to_fcast forNumbercolumns lives in the shared agent parser (condition_tree_parser.rb) and affects all datasources; this PR fixes it locally where it breaks Zendesk. A broader look at the parser's numeric coercion for primary keys is worth a separate ticket.🤖 Generated with Claude Code
Note
Coerce id filter values to integers in Zendesk datasource PK lookups
Adds a
normalize_idhelper toBaseCollectionthat converts values like1.0or"1"to integers usingInteger(value, exception: false), falling back to the original value on failure. Theextract_id_lookupmethod now applies this normalization for bothEQUALandINid filters before passing ids to Zendesk API calls.Macroscope summarized a2eff83.