https://github.com/christian-byrne/resolve-duplicate-node-names
https://github.com/christian-byrne/resolve-duplicate-node-names
Science Score: 26.0%
This score indicates how likely this project is to be science-related based on various indicators:
-
○CITATION.cff file
-
✓codemeta.json file
Found codemeta.json file -
✓.zenodo.json file
Found .zenodo.json file -
○DOI references
-
○Academic publication links
-
○Committers with academic emails
-
○Institutional organization owner
-
○JOSS paper metadata
-
○Scientific vocabulary similarity
Low similarity (10.5%) to scientific vocabulary
Repository
Basic Info
- Host: GitHub
- Owner: christian-byrne
- Language: Python
- Default Branch: main
- Size: 143 KB
Statistics
- Stars: 1
- Watchers: 1
- Forks: 0
- Open Issues: 0
- Releases: 0
Metadata Files
README.md
ComfyUI Node Duplicate Resolution
This repository provides a complete workflow for identifying and resolving duplicate node names in the ComfyUI ecosystem. When multiple packages define nodes with the same name, users experience conflicts and confusion. This system systematically resolves these conflicts through prioritization and name claiming.
🎯 Problem Statement
Multiple ComfyUI packages often define nodes with identical names (e.g., "SaveText", "LoadImage", "StringReplace"), causing: - User confusion about which package provides which functionality - Search result conflicts in the ComfyUI interface - Installation conflicts between packages
📊 Current Status
- 957 duplicate node names identified across different packages
- 464 conflicts resolved (65% resolution rate) through automated and manual processes
- 250 conflicts remaining for future resolution
🔄 Complete Workflow
Stage 1: Data Collection
```bash
Download latest node data from production database
./download-db.sh
``
**Generates**:nodes_data.sql` (211MB of node/package data)
Stage 2: Duplicate Detection
Automated SQL queries identify exact node name matches across different packages.
Output: duplicate-node-names.json containing 957 duplicate entries
json
{
"name": "SaveText",
"distinct_node_count": 3,
"total_record_count": 15,
"node_ids": "package1,package2,package3"
}
Stage 3: Analysis & Prioritization
Run analysis scripts to understand conflict scope and impact:
```bash
Analyze which packages cause the most conflicts
python analyzepriorityimpact.py
Identify automatically resolvable conflicts
python analyzeresolvableduplicates.py
Check current resolution progress
python analyzeresolutionstatus.py ```
Stage 4: Resolution Strategy
The system resolves conflicts through two complementary mechanisms:
4a. Search Priority Changes (326 conflicts resolved)
Globally adjust package search rankings: - Test packages: Set priority to 10 (lowest ranking) - Fork packages: Set priority to 6-8 (lower than originals) - Authoritative packages: Keep priority 5 (default/highest)
4b. Node Name Claiming (138 additional nodes resolved)
Assign specific node names to authoritative packages: - "OllamaGenerate" → claimed by "comfyui-ollama" - "ShowText" → claimed by "comfyui-show-text" - etc.
Stage 5: Resolution Tools
Automated Resolution
```bash
Use download count heuristics (3x difference threshold)
python simple_resolver.py ```
Manual Resolution
```bash
Interactive tool for complex conflicts requiring human judgment
python manual_resolver.py ```
Final Cleanup
```bash
Handle remaining edge cases
python resolve_remaining.py ```
Stage 6: Generate Database Updates
```bash
Analyze resolutions and determine what's actually resolved
python resolution_engine.py ```
Generates: duplicate-resolution-queries.sql with production-ready SQL:
- UPDATE statements for search priority changes
- INSERT statements for node name claims
- Verification queries
Stage 7: Verification
```bash
Validate resolution counts match expectations
python final_verification.py ```
Stage 8: Database Deployment
Execute the generated SQL against production database:
sql
-- Updates nodes.search_priority field
-- Inserts into preempted_node_names table
-- Includes verification queries for safety
📁 File Structure
Core Data Files
duplicate-node-names.json- All identified duplicates (957 entries)nodes_data.sql- Local copy of production database (211MB)duplicate-resolution-results.json- Final resolution summaryduplicate-resolution-queries.sql- Production-ready SQL updates
Resolution State
resolution-cache.json- All resolution decisions and API cacheunresolved_conflicts.json- Remaining conflicts after processing
Scripts by Purpose
Data Collection
- download-db.sh - Download latest data from Supabase
Analysis
- analyze_priority_impact.py - Impact analysis
- analyze_resolution_status.py - Progress tracking
- analyze_resolvable_duplicates.py - Auto-resolution identification
Resolution Tools
- resolution_engine.py - Main resolution logic
- simple_resolver.py - Automated resolution via heuristics
- manual_resolver.py - Interactive manual resolution
- resolve_remaining.py - Final cleanup
Utilities
- final_verification.py - Validates results
- clear_bad_cache.py - Cache management
- find_discrepancy.py - Data consistency checks
Documentation
- process-raw-human-text.md - Manual resolution guidelines
- openapi.yml - API specification
🚀 Quick Start
Setup Environment ```bash
Create .env file with database connection
echo "SUPABASECONNECTIONSTRING=postgres://..." > .env ```
Run Full Pipeline ```bash
Download latest data
./download-db.sh
# Analyze conflicts python analyzepriorityimpact.py
# Run automated resolution python simple_resolver.py
# Handle remaining conflicts manually python manual_resolver.py
# Generate SQL updates python resolution_engine.py
# Verify results python final_verification.py ```
- Deploy to Production ```bash # Review generated SQL cat duplicate-resolution-queries.sql
# Execute against production database psql $SUPABASECONNECTIONSTRING -f duplicate-resolution-queries.sql ```
💡 Resolution Logic
Automatic Resolution Criteria
- 3x Download Difference: Package with 3x+ more downloads wins
- Test vs Production: Production packages always win over test packages
- Original vs Fork: Original repositories win over forks
- Recency: More recently updated packages preferred
Manual Resolution Factors
- Package popularity and community adoption
- Code quality and maintenance status
- Feature completeness and documentation
- Developer reputation and project stability
📈 Results Summary
| Metric | Count | Percentage | |--------|-------|------------| | Total Duplicates | 957 | 100% | | Resolved via Priority | 326 | 34% | | Resolved via Claims | 138 | 14% | | Total Resolved | 464 | 48% | | Remaining Conflicts | 493 | 52% |
🔧 Configuration
Required Environment Variables
bash
SUPABASE_CONNECTION_STRING=postgres://user:pass@host:port/db
Cache Management
- Resolution decisions cached in
resolution-cache.json - API calls cached to respect rate limits
- Clear cache with
python clear_bad_cache.py
🤝 Contributing
- Run analysis scripts to understand current state
- Use manual resolver for complex conflicts
- Test resolution logic with verification scripts
- Update documentation for new processes
📚 Additional Resources
Owner
- Name: Christian Byrne
- Login: christian-byrne
- Kind: user
- Location: San Francisco
- Company: Comfy-Org
- Twitter: c__byrne
- Repositories: 100
- Profile: https://github.com/christian-byrne
GitHub Events
Total
- Push event: 3
- Create event: 1
Last Year
- Push event: 3
- Create event: 1
Committers
Last synced: about 1 year ago
Top Committers
| Name | Commits | |
|---|---|---|
| bymyself | c****e@c****g | 8 |
Committer Domains (Top 20 + Academic)
Issues and Pull Requests
Last synced: about 1 year ago