JS/TS: fetch(`${BASE_URL}/v1/x`) with a base-URL constant produces no HTTP_CALLS (template flattened to "{}/v1/x" and rejected)

[akynte]

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

1. Code: the snippet above in client.ts, in its own git repo.
2. Commands:

codebase-memory-mcp cli index_repository '{"repo_path":"/path/to/client"}'
codebase-memory-mcp cli get_graph_schema '{"project":"<client>"}'

3. Output: there is no HTTP_CALLS edge 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

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.