russell@unturf.com
80b26e82b6
vllm-0001: punica_wrapper/utils.py convert_mapping() calls lora_index_to_id.index(x) per token in batch — O(B*L) where B=batch_size, L=loaded_loras. Code has "TODO index can be slow" comment. Fix: pre-build dict for O(1) lookup. 7x at B=2000/L=64. Ollama: all slices.Contains on bounded slices (1-8 items). LangChain: orchestration code, all membership bounded by k param.
1.2 KiB
1.2 KiB
LangChain — CWE-407 Scan Result: CLEAN
Date: 2026-03-30 Target: https://github.com/langchain-ai/langchain (Python) Scanner: Agent Blackops CWE-407 sweep Focus: chain/agent tool dedup, document loader dedup, vectorstore result dedup, callback handler membership
Findings
No CWE-407 defects found. The codebase is primarily orchestration/configuration code, not heavy data processing.
Examined patterns:
- multi_vector.py line 108-111:
if d.metadata[self.id_key] not in ids— O(D^2) dedup, but bounded by search k parameter (typically k=4..20). Not a practical defect. - jsx.py line 66-68:
if tag not in component_tags— O(T^2) dedup of JSX component tags, bounded by typical JSX file size (tens of unique tags). - langchain_core: Uses
dictfor visited tracking (function_calling.py), sets for membership tests throughout. Clean patterns. - partners/: No linear membership patterns in loops.
- text-splitters/: No scalable dedup patterns.
LangChain's architecture is inherently bounded — document counts come from vector search k, tool lists are developer-defined (typically < 20), callback lists are small. No data-proportional linear scans inside loops.