Priority
Low. Dead code with misleading intent, not a user-facing fault. Found while writing twilio/twilio.controller.spec.js.
What the code says
twilio/twilio.controller.js, queryItem():
const items = allItems.filter(
({ itemType }) => !itemName.includes('Catalyst') && [2, 3, 4].includes(itemType ?? -1),
);The itemName.includes('Catalyst') clause reads as "a search for a catalyst should return nothing rather than the base weapon". It never does that, for two independent reasons.
Why it cannot fire
It is unreachable from the only path that calls it. request() builds its search term with const message = strippedMessage.toLowerCase() (line 547) and passes it straight to queryItem(message) (line 651). The guard compares against a capital-C 'Catalyst', so a lowercased term never matches. Only a direct call to queryItem with a capitalised term reaches it.
It is redundant even if it did fire. Checked against the manifest in databases/destiny2 — of the items whose name matches /catalyst/i, the itemType histogram is:
| itemType |
count |
| 19 |
132 |
| 20 |
76 |
| 0 |
5 |
| 12 |
3 |
None are 2, 3 or 4, so the [2, 3, 4].includes(itemType) clause beside it already removes every catalyst. Zero catalyst items survive to where the name guard would matter.
Why there is no user impact
World2.getItemByName matches items whose name contains the search term, so "gjallarhorn catalyst" matches only items literally named that — which are itemType 19 or 20 and get filtered out regardless. The sender gets a no-results reply either way, which is the intended outcome. Nothing observable changes whether the guard is there or not.
Also worth noting
The clause is term-level but sits inside a per-item predicate, so it is re-evaluated once per candidate item while being constant across the loop. Harmless, but it is part of why the intent reads unclearly.
Suggested resolution
Delete the clause and let the itemType filter carry the rule it already enforces, with a comment recording that catalysts are excluded by type. If the intent was in fact broader — say, suppressing a base weapon result when someone searches for its catalyst — that is a different feature and needs stating explicitly, because the current substring search never returns the base weapon for such a query anyway.
Coverage
twilio/twilio.controller.spec.js pins both halves: that the guard fires only on a capitalised direct call, and that request() does not reach it. Both cases need a weapon-typed item named 'Catalyst', which the manifest does not contain — which is itself the clearest evidence the guard does nothing.
Priority
Low. Dead code with misleading intent, not a user-facing fault. Found while writing
twilio/twilio.controller.spec.js.What the code says
twilio/twilio.controller.js,queryItem():The
itemName.includes('Catalyst')clause reads as "a search for a catalyst should return nothing rather than the base weapon". It never does that, for two independent reasons.Why it cannot fire
It is unreachable from the only path that calls it.
request()builds its search term withconst message = strippedMessage.toLowerCase()(line 547) and passes it straight toqueryItem(message)(line 651). The guard compares against a capital-C'Catalyst', so a lowercased term never matches. Only a direct call toqueryItemwith a capitalised term reaches it.It is redundant even if it did fire. Checked against the manifest in
databases/destiny2— of the items whose name matches/catalyst/i, theitemTypehistogram is:None are 2, 3 or 4, so the
[2, 3, 4].includes(itemType)clause beside it already removes every catalyst. Zero catalyst items survive to where the name guard would matter.Why there is no user impact
World2.getItemByNamematches items whose name contains the search term, so "gjallarhorn catalyst" matches only items literally named that — which are itemType 19 or 20 and get filtered out regardless. The sender gets a no-results reply either way, which is the intended outcome. Nothing observable changes whether the guard is there or not.Also worth noting
The clause is term-level but sits inside a per-item predicate, so it is re-evaluated once per candidate item while being constant across the loop. Harmless, but it is part of why the intent reads unclearly.
Suggested resolution
Delete the clause and let the
itemTypefilter carry the rule it already enforces, with a comment recording that catalysts are excluded by type. If the intent was in fact broader — say, suppressing a base weapon result when someone searches for its catalyst — that is a different feature and needs stating explicitly, because the current substring search never returns the base weapon for such a query anyway.Coverage
twilio/twilio.controller.spec.jspins both halves: that the guard fires only on a capitalised direct call, and thatrequest()does not reach it. Both cases need a weapon-typed item named 'Catalyst', which the manifest does not contain — which is itself the clearest evidence the guard does nothing.