fix(#1135): Viator client must send Accept-Language (live sandbox 400 INVALID_HEADER_VALUE)#1207
Conversation
… INVALID_HEADER_VALUE) The Viator Partner API REQUIRES an Accept-Language header — without it every call returns 400 INVALID_HEADER_VALUE. The P1b ViatorContentClient only sent `Accept: application/json;version=2.0` + the exp-api-key, so ALL live ingest (destinations/tags/products) would 400. P1b was fixture-tested with a mocked HTTP layer, so the missing header was invisible until the live sandbox dry-run (VIATOR_API_KEY just provisioned) hit the 400. Fix: add `Accept-Language: en-US` to the client's shared versionHeaders (used by all feeds + getDetails). Verified live against sandbox after the fix: destinations 3388/3388 mapped, tags 1263/1263, products 2 pages/100 mapped, cursor advanced, 0 errors. Adds a regression spec that spies on the outgoing request and asserts all three required headers (exp-api-key + versioned Accept + Accept-Language) on the destinations and products feeds — the guard the fixture-only tests lacked. Refs #1135
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe Viator content client now sends ChangesViator request header contract
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
apps/api/src/external-apis/providers/viator/viator-content.client.spec.tsOops! Something went wrong! :( ESLint: 8.57.1 Error: ESLint configuration in --config is invalid:
apps/api/src/external-apis/providers/viator/viator-content.client.tsOops! Something went wrong! :( ESLint: 8.57.1 Error: ESLint configuration in --config is invalid:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
What
One-line fix surfaced by the live sandbox dry-run verification of #1135 Spec B Phase 1 (now that
VIATOR_API_KEYis provisioned).Refs #1135.The Viator Partner API requires an
Accept-Languageheader — without it every call returns400 {"code":"INVALID_HEADER_VALUE","message":"Invalid value for header: Accept-Language"}. The mergedViatorContentClientsent onlyAccept: application/json;version=2.0+exp-api-key, so all live ingest (destinations/tags/products/details) would have 400'd. P1b was fixture-tested with a mocked HTTP layer, so the missing header was invisible until a real server saw it.Confirmed via curl: same call without
Accept-Language→ 400; withAccept-Language: en-US→ 200.Fix
Add
'Accept-Language': 'en-US'to the client's privateversionHeadersgetter — the shared header source forgetDestinations/getTags/getProductsModifiedSince/getDetails. (Hardcodeden-USis fine for now; app is en-only. Config-driving it can wait for real localization.)Live verification (sandbox, zero writes) — after the fix
Regression test
New
viator-content.client.spec.tsspies on the actual outgoing request and asserts all three required headers (exp-api-key+ versionedAccept+Accept-Language) on the destinations and products feeds — the guard the fixture-only suite lacked. 2/2 pass.Verification
tscclean for the touched files;git diff --checkclean.versionHeaders(no bypass), the auth-header merge preservesAccept/Accept-Language, and the spec verifies the real outgoing request. Codex re-ran the suite (2/2).This unblocks Phase-1 live ingest. The catalog still only ingests on Prod (Rule #5/FDW) with the prod key (post-certification); this fix makes the dry-run + future live ingest actually authenticate against Viator.
🤖 Generated with Claude Code
Summary by CodeRabbit