useContractorOnboarding calls useCreateEmployment() with no options (src/flows/ContractorOnboarding/hooks.tsx:289), so POST /v1/employments always sends json_schema_version=1, Onboarding's DEFAULT_VERSION.
The schema itself is fetched with getBasicInformationSchemaVersion(options) from ContractorOnboarding/utils.ts, which respects options.jsonSchemaVersion.employment_basic_information.
Failure scenario: a partner passes jsonSchemaVersion: { employment_basic_information: 2 } (or 'latest'). The form renders and validates against v2, but the create request asks the backend to validate against v1. Fields added in v2 could be rejected or dropped.
Today both defaults are 1, so partners on the default version aren't affected.
Suggested fix: pass the flow's options through, e.g. useCreateEmployment(options as $TSFixMe), the same way useUpdateEmployment already gets them on the next line. Then add a test that asserts the query param on the create request.
Found while reviewing #1455.
🤖 Generated with Claude Code
useContractorOnboardingcallsuseCreateEmployment()with no options (src/flows/ContractorOnboarding/hooks.tsx:289), soPOST /v1/employmentsalways sendsjson_schema_version=1, Onboarding'sDEFAULT_VERSION.The schema itself is fetched with
getBasicInformationSchemaVersion(options)fromContractorOnboarding/utils.ts, which respectsoptions.jsonSchemaVersion.employment_basic_information.Failure scenario: a partner passes
jsonSchemaVersion: { employment_basic_information: 2 }(or'latest'). The form renders and validates against v2, but the create request asks the backend to validate against v1. Fields added in v2 could be rejected or dropped.Today both defaults are 1, so partners on the default version aren't affected.
Suggested fix: pass the flow's options through, e.g.
useCreateEmployment(options as $TSFixMe), the same wayuseUpdateEmploymentalready gets them on the next line. Then add a test that asserts the query param on the create request.Found while reviewing #1455.
🤖 Generated with Claude Code