#!/bin/bash
# Look for how render() is invoked from the SSR entry / nitro handler and
# whether there is any surrounding serialization. Also confirm renderApplication
# is fully awaited before the next request can call render() again.
rg -nP -C5 '\brender\s*\(' packages/router/server/src
rg -nP -C3 'renderApplication' packages/router/server/src
fd -t f 'server.*\.(mjs|ts|js)$' -E node_modules -E dist \
  --exec rg -nP -C3 "from '@analogjs/router/server'" {} \;

fd -t f 'handler\|entry\|middleware' packages/router -E node_modules -E dist | head -20

rg -nP -l 'defineEventHandler\|renderSSR\|export.*render' packages/ -E node_modules -E dist | grep -E '\.(ts|js|mjs)$' | head -20

fd -t f '\.(ts|js|mjs)$' apps/ -E node_modules -E dist -E '.next' | xargs rg -l 'renderSSR\|from.*@analogjs/router' 2>/dev/null | head -10

# Search for actual calls to render() function (not imports)
rg -nP 'render\s*\(' packages/router/server/src --type ts -A 2 -B 2

# Look at the full render.ts file to understand the complete flow
cat -n packages/router/server/src/render.ts | head -100

# Search for where the render factory result is called/exported
rg -nP 'export.*render|return.*render' packages/router/server/src --type ts

# Look for test files that might test concurrent rendering
fd -t f 'spec\|test' packages/router/server --type ts | xargs cat

# Search for where the render function returned value is actually invoked
rg -nP 'render\(.*,.*,.*\)' packages/ apps/ -t ts -t js --type-add 'ts:*.ts' --type-add 'js:*.js' -A 2 | head -40

# Look at generated template files to understand how render() is used
fd -t f 'handler\|ssr' apps/ | grep -v node_modules | grep -v dist

# Search for defineEventHandler patterns which is Nitro's way of defining SSR
rg -nP 'defineEventHandler|export default' packages/ apps/ --type ts --type js -A 3 | grep -B 3 -A 3 render | head -50

# Look at the generated index.ts exports to understand the package surface
cat packages/router/server/src/index.ts

# Look at the actual Nitro handler that invokes render()
cat -n packages/vite-plugin-nitro/src/lib/utils/renderers.ts

# Search for how main.server.ts exports are used in the Nitro handler
rg -nP 'main\.server|__RENDER_FUNCTION__' packages/vite-plugin-nitro/src -A 5 -B 2

# Check if there are any comments or documentation about concurrency
rg -nP 'concurr|serial|parallel|mutex|lock|atomic' packages/router/server/src -A 2 -B 2

# Check if there are any concurrent/parallel rendering tests
fd -t f 'spec\|test' packages/router --exec cat {} \;

# Look at the h3/Nitro documentation or check if eventHandler enforces serialization
rg -nP 'eventHandler|h3' packages/vite-plugin-nitro/src/lib/utils/renderers.ts -B 3 -A 8

# Search for any existing issues or comments about this in the codebase
rg -nP 'race|concurrent|parallel|serial' packages/router -i

# Check Nitro's event handling model - see if requests are serialized or concurrent
rg -nP 'from.*h3|from.*nitro' packages/ --type ts -A 2 -B 2 | head -50

# Check git history for render.ts to see recent changes
git log --oneline packages/router/server/src/render.ts | head -20

# Check if there are any TODOs or FIXMEs related to concurrency/serialization
rg -nP 'TODO|FIXME|XXX|HACK' packages/router/server/src/render.ts -B 2 -A 2

# Search for any mutex/async lock implementations in the codebase
rg -nP 'Mutex|Lock|serialize|queue|drain' packages/ --type ts --type js -i | head -30

# Get detailed info about the commit that introduced resetComponentDefTViews
git show 320acf94 --stat

# See the full diff of that commit
git show 320acf94 | head -150

# Check if there are any related PRs or issues mentioned
git log 320acf94^..320acf94 --format=fuller

# Search for any concurrency-related discussions in PR metadata or comments
rg -nP 'concurrent|parallel|race|lock|serial|mutex' . --type md --type txt -i | grep -v node_modules | head -20

# Look at the Nitro handler more closely to understand the complete flow
rg -nP 'eventHandler|renderer|import' packages/vite-plugin-nitro/src/lib/utils/renderers.ts | head -30

# Check if there's any documentation or TODO about concurrency in i18n code
rg -nP 'i18n|locale|render' packages/router/server/src --type ts -B 2 -A 2 | grep -i -E 'concurrent|todo|fixme|race|serial|lock' -B 2 -A 2

# Look at the i18nDefRegistryPlugin to understand how it works
fd -t f 'i18n.*plugin' packages/ -E node_modules | head -5

# Check i18n provider code to understand the full locale switching flow
rg -nP 'provideI18n|loadTranslations' packages/router -A 5 --type ts | head -50

# Look for i18n tests that might test concurrent/parallel rendering
fd -t f 'i18n.*spec' packages/router/src --exec cat {} \; 2>/dev/null | head -100

# Check if there are any load tests or concurrent request tests
find packages/router apps -name '*.spec.ts' -o -name '*concurrent*' -o -name '*parallel*' | head -20

# Look at actual usage - does anyone call render() concurrently?
rg -nP 'await.*render\(' packages/ apps/ --type ts -B 3 -A 3 | head -60

# Check Nitro's eventHandler documentation or behavior
rg -nP 'h3|eventHandler' packages/vite-plugin-nitro/src/lib/ -A 5 --type ts | grep -v node_modules | head -50

# Look at how h3/Nitro handles concurrent requests - check if there's built-in serialization
rg -nP 'concurrent|serial|queue|drain' packages/vite-plugin-nitro -i --type ts

# Check if the render function is called in sequence or concurrently in tests
rg -nP 'renderer\(|render\(' packages/vite-plugin-nitro -B 5 -A 5 --type ts | head -80

# Look at the actual test patterns for the i18n feature
cat packages/router/src/lib/i18n/provide-i18n.spec.ts | grep -A 20 'concurrent\|parallel' || echo "No concurrent tests found"

# Check if there are any integration tests that exercise the SSR renderer
fd -t f 'ssr\|server.*spec' packages/router/server/src

# Check if the code is documented as being for prerender-only
rg -nP 'prerender|single.*thread' packages/router/server/src -i

# See the full render() function and its context
cat -n packages/router/server/src/render.ts | sed -n '37,84p'

# Check nitro prerender behavior to see if it's truly single-threaded
rg -nP 'prerender|concurrency|parallel' packages/vite-plugin-nitro/src/lib/build-server.ts -i -B 2 -A 2

# Look for any comments or documentation about the expected usage
rg -nP 'TODO|FIXME|NOTE|@param|@returns' packages/router/server/src/render.ts -B 2 -A 2

# Check the actual Nitro prerender documentation or behavior in this codebase
rg -nP 'prerender.*function|export.*prerender' packages/vite-plugin-nitro/src --type ts -A 10 | head -50

# Determine if Nitro's prerender is single-threaded or concurrent
rg -nP 'concurrency|workers|threads|parallel' packages/vite-plugin-nitro -i --type ts

# Check if there are runtime SSR tests (not just prerender)
fd -t f 'e2e\|integration' apps -name '*.spec.ts' | xargs grep -l 'render\|ssr' 2>/dev/null | head -5

# Look at the commit message more carefully and check related comments
git show 320acf94 | grep -i 'concurr\|serial\|parallel\|race\|thread' -B 2 -A 2

# Check if there's documentation about when/how render() should be used
rg -nP 'render|SSR|server' packages/router/server/src --type ts --type md -B 1 -A 1 | grep -E '(render|SSR|concurrent|parallel)' | head -30

# Look for any usage patterns in the codebase
rg -nP 'from.*@analogjs/router/server|import.*render' packages/ apps/ --type ts -B 1 -A 3 | head -50

# Check if Nitro has any built-in request queuing/serialization
rg -nP 'serialize|queue|mutex|lock' packages/vite-plugin-nitro/src/lib/vite-plugin-nitro.ts -i