Repository navigation
JS/TS: fetch(${BASE_URL}/v1/x) with a base-URL constant produces no HTTP_CALLS (template flattened to "{}/v1/x" and rejected) #2540
Description
Version
0.11.0 (release). Also reproduced on main @ 96c3f41 built from source.
Platform
Linux (x64)
Install channel
GitHub release archive / install.sh / install.ps1
Binary variant
standard
What happened, and what did you expect?
A client URL built as a template literal starting with a substitution, which is the
common "base URL from config/constant" pattern, produces no HTTP_CALLS edge:
const PAYMENTS_URL = "http://payments:8080";
export async function createPayment(body: unknown) {
return fetch(`${PAYMENTS_URL}/v1/payments`, { method: "POST", body: JSON.stringify(body) });
}The same call written as fetch("http://payments:8080/v1/payments", ...) produces
HTTP_CALLS and links via cross-repo-intelligence (cross_http_calls: 1) to a Go server
with http.HandleFunc("/v1/payments", h). The template version gives cross_http_calls: 0.
Expected: an HTTP_CALLS edge for path /v1/payments. Ideally the constant is resolved
(the same-file const is a literal). At minimum, the leading substitution should be
treated as an unknown host and the literal path kept.
Reproduction
- Code: the snippet above in
client.ts, in its own git repo. - Commands:
codebase-memory-mcp cli index_repository '{"repo_path":"/path/to/client"}'
codebase-memory-mcp cli get_graph_schema '{"project":"<client>"}'
- Output: there is no
HTTP_CALLSedge type. With the literal URL there is
HTTP_CALLS 1.
Attached repro.sh, section "Issue 4".
Suspected cause (from reading the source at 96c3f41)
cbm_template_string_text() (internal/cbm/helpers.c:1812, #1006) replaces every
${...} with {}, so the URL becomes "{}/v1/payments". The client-URL gate then
requires u[0] == '/' || strstr(u, "://"), for example in src/pipeline/pass_calls.c
near line 778, and rejects it. The #1006 tests cover a literal leading path
(`/api/v1/things/${id}`) but not a leading substitution. Resolving identifier
substitutions through the existing string-constant lookup, or accepting a leading {}
followed by / as "unknown host + path", would cover it.
Full self-contained script (creates throwaway repos in a temp dir, isolated cache): see attached repro.sh.txt, section "Issue N". Run with bash repro.sh.txt
Logs
"== Issue 4: TS template-literal URL with a base-URL constant produces no HTTP_CALLS"
for v in template literal; do
if [ $v = template ]; then
repo "i4-$v" client.ts <<'TS'
const PAYMENTS_URL = "http://payments:8080";
export async function createPayment(body: unknown) {
return fetch(`${PAYMENTS_URL}/v1/payments`, { method: "POST", body: JSON.stringify(body) });
}
TS
else
repo "i4-$v" client.ts <<'TS'
export async function createPayment(body: unknown) {
return fetch("http://payments:8080/v1/payments", { method: "POST", body: JSON.stringify(body) });
}
TS
fi
commit "i4-$v"; index "i4-$v"
done
check "HTTP_CALLS, fetch(\`\${PAYMENTS_URL}/v1/payments\`) " "$(count i4-template HTTP_CALLS)" 1
check "HTTP_CALLS, fetch(\"http://payments:8080/v1/payments\")" "$(count i4-literal HTTP_CALLS)" 1
check "CROSS_HTTP_CALLS template client -> legacy Go server" "$(cross i4-template i1-legacy cross_http_calls)" 1
check "CROSS_HTTP_CALLS literal client -> legacy Go server" "$(cross i4-literal i1-legacy cross_http_calls)" 1
echo "workdir: $W"
Diagnostics trajectory (memory / performance / leak issues)
Project scale (if relevant)
No response
Confirmations
- I searched existing issues and this is not a duplicate.
- My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.
Activity