fix(hubspot): allow string values to match datetime fields in schema comparison#3827
Open
harsh-joshi99 wants to merge 3 commits into
Open
fix(hubspot): allow string values to match datetime fields in schema comparison#3827harsh-joshi99 wants to merge 3 commits into
harsh-joshi99 wants to merge 3 commits into
Conversation
…comparison HubSpot datetime fields accept plain string values such as Unix epoch timestamps. The schema comparison was incorrectly blocking these by classifying them as string:text and rejecting them against datetime:date fields. Added a coercion rule in compareProps() consistent with existing string:text -> enumeration:select and string:text -> string:textarea rules. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates HubSpot upsertObject schema comparison to treat payload-inferred string:text values as compatible with HubSpot datetime:date fields, unblocking Unix-epoch timestamp strings that otherwise fail strict type matching before requests reach HubSpot validation.
Changes:
- Added a schema-compatibility rule in
compareProps()to allowstring:textto matchdatetime:date. - Added an integration test ensuring an epoch string payload no longer fails schema comparison.
- Added unit tests covering
format()type detection for representative value shapes.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
packages/destination-actions/src/destinations/hubspot/upsertObject/functions/schema-functions.ts |
Adds a coercion rule in compareProps() to accept epoch-like string values for HubSpot datetime fields. |
packages/destination-actions/src/destinations/hubspot/upsertObject/__tests__/upsert-property-mismatch.test.ts |
Adds a regression test ensuring epoch strings don’t fail before calling HubSpot. |
packages/destination-actions/src/destinations/hubspot/upsertObject/__tests__/schema-functions.test.ts |
Adds new unit tests for objectSchema()/format() type detection across common input types. |
Comment on lines
+169
to
+177
| if ( | ||
| prop1.type === HSPropType.String && | ||
| prop1.fieldType === HSPropFieldType.Text && | ||
| prop2.type === HSPropType.DateTime && | ||
| prop2.fieldType === HSPropFieldType.Date | ||
| ) { | ||
| // string values (e.g. Unix epoch strings) are valid for HubSpot datetime fields | ||
| return true | ||
| } |
…tibility When the cache stores a payload-inferred string:text schema (from an epoch string event) and a subsequent event sends an ISO datetime string (inferred as datetime:date), the cache comparison would throw a mismatch. Making the coercion bidirectional prevents time-dependent failures when the same HubSpot datetime property arrives in different string encodings across events. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
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.
Summary
"1780382814"or"1780382814000"), but our schema comparison incompareProps()was classifying these asstring:textand rejecting them against HubSpot'sdatetime:datefieldsstring:text(payload-inferred) to matchdatetime:date(HubSpot schema), consistent with the existing rules forstring:text → enumeration:selectandstring:text → string:textareaJIRA: https://twilio-engineering.atlassian.net/browse/STRATCONN-6042
Root Cause
BigQuery RETL serializes timestamp columns as Unix epoch strings. When these arrive in the
upsertObjectaction,format()correctly identifies them as plain strings (they don't match the ISO datetime regex), tagging themstring:text.compareProps()then seesstring:textvsdatetime:dateand throws a type mismatch error before the request ever reaches HubSpot.Test plan
Local Testing:
upsert-property-mismatch.test.tsconfirming epoch string"1780382814"passes schema comparison against adatetime:dateHubSpot field without throwingschema-functions.test.tscoveringformat()type detection for all value types (date string, datetime string, epoch string, number, boolean, plain string)upsertObjecttests pass"1780382814000"sent tohs_appointment_start(datetime:date) resulted in a 201 Created with HubSpot storing the value as"2026-06-02T06:46:54Z"🤖 Generated with Claude Code