Migration stay-scout-hub#137
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
simantak-dabhade
left a comment
There was a problem hiding this comment.
Review: changes requested
The README is the best-written one in this batch (mermaid diagrams, per-API usage examples, clean setup block) — but the code doesn't match what it promises. That's the headline issue.
🔴 README promises TinyFish Search + Fetch, code uses Groq hallucinations
README lines 25-53 claim:
/api/discover-areasusesclient.search.query()+client.fetch.get_contents({ urls, format: "markdown" })to find real travel guides and extract neighborhoods./api/discover-platformsusesclient.search.query()to find booking platforms for the destination.
Actual code:
src/app/api/discover-areas/route.tsimportsgroq-sdk, promptsllama-3.3-70b-versatilefor neighborhood names, falls back to a hardcoded list (generateFallbackAreas). No TinyFish call anywhere. The LLM is making up neighborhoods from training data, not extracting from real travel guides.src/app/api/discover-platforms/route.tssame story — prompts Groq for platform URLs with a hugegenerateFallbackPlatformshardcoded list.
Either:
- Make the code match the README — these two routes should actually use
client.search.query+client.fetch.get_contentsas documented. The README's code snippets are basically the implementation — copy them in. - Rewrite the README to match the code — admit these two routes are Groq-only, drop the Search/Fetch mentions, redraw the architecture diagram.
Option 1 is much better — it's what makes this a "showcase all three TinyFish APIs" recipe. Option 2 makes the recipe way less interesting.
🔴 Build fails — static image import type error
./src/components/HeroSection.tsx:44:11
Type error: Type 'StaticImageData' is not assignable to type 'string'.
import hotelHero from '@/assets/hotel-hero.jpg' gives you Next's StaticImageData object, not a URL string. Two fixes:
- Preferred: use Next's
<Image>component (import Image from 'next/image') and<Image src={hotelHero} .../>. - Quick: keep the raw
<img>and change tosrc={hotelHero.src}.
🔴 Mino still in code
Two comment references — small but explicit:
src/hooks/useAreaSearch.ts:36—// Stage 2: Research each area in parallel via Minosrc/hooks/useHotelSearch.ts:39—// Stage 2: Check each platform in parallel via Mino
Replace with "TinyFish" (or just "agent").
🟡 Dead src/components/ui/ dir
6 shadcn files, none imported by app code (grep for @/components/ui across src/{app,components,hooks} returns zero). Much smaller dump than other PRs in this batch so less urgent, but still worth deleting for clone-runnable cleanliness.
🟡 Nits (not blocking)
- PR body is empty.
- Next 15.3.3 — outdated vs pack, repo-wide sweep will handle.
✅ What's working well
/api/research-area/route.ts+/api/check-platform/route.ts— use SDK idiomatically.- README structure is genuinely excellent once the lies are fixed.
.env.examplehas URL comments for both keys.- No env leak.
- 4-route architecture showing off multiple TinyFish APIs is a great recipe concept.
Fix the README/code mismatch (preferably by writing the real SDK calls), unbreak the build, purge the Mino comments, and this is a strong recipe.
No description provided.