TS/JS: a call through a chained receiver (chrome.storage.local.get, this.map.get, a.b.text()) reaches the resolver as the bare method name and exact-matches any project symbol with that name

[bompus]

What happens

In the TS/JS extractor, a call_expression whose callee is a member_expression keeps the receiver only when the receiver is a plain identifier (recv.method, codegraph-kernel/src/tsjs/extractors.rs extract_call, and the same branch in TreeSitterExtractor.extractCall). Any other receiver, a nested member expression, a subscript, a call, collapses to the bare method name:

source	reference recorded
chrome.storage.local.get([key])	get
this._espnPlayerById.get(id) (a Map)	get
settled.value.text() (a Response)	text
thHeaders[0].text()	text
document.querySelector(sel)	document.querySelector (identifier receiver, kept, and JS_BUILT_INS drops it)

The bare name then goes through matchByExactName, where a single same-named project node wins at confidence 0.9. Nothing downstream can tell that the receiver was a runtime global or a builtin container, because that information is gone before resolution starts.

Measured

Real TS repo, 584 files, indexed on main + #1706:

• 119 calls edges named get and 117 named set land on an object-literal storage wrapper's get / set methods. Every one of them is a Map#get, Map#set, chrome.storage.local.get/set or URLSearchParams#get call. Two of them are the wrapper's own methods calling chrome.storage.local.get/set, so the wrapper calls itself.
• 8 calls edges named querySelector land on an interface member AutopickDoc::querySelector (with fix(extraction): index TypeScript interface members (#1638) #1686's interface members; without it they would land on any function so named). The calls are el.shadowRoot.querySelector(...) and this.root.querySelector(...).
• 4 calls edges named observe / disconnect from MutationObserver instances land on two helper functions in a test file.

#1691 (#1496) fixes the this.<field>.<method> subset by keeping the field and reading its declared type, and declines when the type is not a project class. The non-this shapes above (chrome.…, x.value.text(), arr[0].text()) are outside its scope and still collapse.

Proposed fix

In the extractor, never drop a chained receiver on the floor. For a nested member_expression / subscript_expression / call_expression receiver, record the chain head plus the method, e.g. chrome.storage.local.get → chrome.….get or the full dotted text (the resolver already handles dotted names in matchByQualifiedName / matchMethodCall, and Java, C++ and Go already encode chains). Then:

1. isBuiltInOrExternal checks the chain head against JS_BUILT_INS, extended with the extension and browser globals that are missing today: chrome, browser, globalThis, navigator, location, history, localStorage, sessionStorage, performance, crypto.
2. A chained call whose head is a local or a parameter with no inferable type declines, the way matchTsThisFieldCall declines, instead of falling through to bare-name matching. A calls edge that is a guess between Map#get and a project get is worse than no edge: it hides the real callee and inflates every caller list for common method names (get, set, text, push, clear, close).

Happy to open a PR if the direction is right; the head-plus-method encoding is the part I would want a maintainer's view on, since it changes the reference names other resolvers see.

[bompus]

I have a fix on my fork and, more usefully, a measurement of what the obvious version of it costs.

The obvious fix is wrong. My first attempt dropped the ref for every TS/JS receiver the extractor cannot name — a deeper chain, a subscript, a call, an await/paren/as wrapper — keeping only a plain identifier and this.<field>. It does kill the bug, but on this repo (588 files, 41.4k edges) it also removed 64 correct project edges, and it broke 10 tests in the suite:

• object-literal-methods — "resolves callers of store actions across files (destructured + chained getState())"
• ui-steps-api-servers (3), ui-steps-cross-tier (2), nextjs (2), react-native-bridge (1)

Those all depend on the bare-name fallback for a chained receiver. The real-world losses had the same shape: window.MyNamespace.doThing(), Vue's intelligence.value.evaluatePlayer(p), obs.liveSources.ingest(row). Each reaches a genuine project symbol that only the bare name finds. So the fallback is load-bearing, and a blanket drop trades far more recall than it buys precision.

The narrow version works. Drop the ref only when the receiver is a member/subscript chain whose root identifier is a host object a project never declares: chrome, browser, document, navigator, performance, console, localStorage, sessionStorage, indexedDB, crypto, globalThis, process, Math, JSON, Object, Array, Reflect, Promise, Intl. A chain rooted there ends in a platform API, so the bare name it used to emit could only ever match an unrelated project symbol.

window is deliberately not in that set — window.MyNs.doThing() reaches a project symbol.

Measured on the same repo, against the same baseline:

	before	after
fabricated calls edges	153	0
real edges lost (line-insensitive diff)	—	0
false self-edges	3	1
import-resolved edges	4,797	4,797
fork suite	4,052 pass / 32 known	4,052 pass / 32 known / 0 fresh

The 153 were all chrome.storage.local.get/set inside a storage wrapper binding to the wrapper's own get/set — including the two self-edges that are not in the source.

This leaves the rest of the issue unfixed on purpose: this.map.get(k) and rows[0].text() still bare-name match. Those need the receiver's type, which is #1496's job, not the extractor's. The host-global gate is the subset that can be fixed without a type.

Branch: fix/chained-receiver-drop on my fork (bompus/codegraph). It mirrors the gate in the Rust kernel's extract_call (tsjs/extractors.rs) — necessary, since TS/JS is routed to the kernel by default — but the Rust side is unverified: no cargo toolchain and no prebuilt .node on this host, so only the TypeScript path was executed. Happy to open a PR if you want it.

[bompus]

Opened as #1710.