# 1. בדיקת כל instances בנפרד
curl -s http://instance1/healthz | jq '.static_version'
curl -s http://instance2/healthz | jq '.static_version'

# 2. בדיקת תהליכים פעילים
ps aux | grep -E 'python|gunicorn|uwsgi' | grep -v grep

# 3. בדיקת קבצי קוד פעילים
lsof -p $(pgrep -f 'python.*your_app') | grep '\.py$'

# 4. בדיקת גרסאות קוד בפועל
curl -X POST http://your-app/debug/code-version -H "Content-Type: application/json" -d '{"files": ["path/to/file.py"]}'

2. ניתוח טכני של בעיית ה-Memory Sort
א. הבנת מגבלת הזיכרון (33,554,432 bytes = 32MB)
מגבלה זו היא ברירת מחדל של MongoDB עבור sort operations
כאשר ה-sort חורג מהמגבלה ולא מוגדר allowDiskUse, מתקבלת השגיאה
ב. פתרונות ברמת ה-Database
// 1. הגדלת מגבלת הזיכרון (לא מומלץ ל-production)
db.adminCommand({setParameter: 1, internalQueryExecMaxBlockingSortBytes: 100 * 1024 * 1024})

// 2. יצירת אינדקסים מתאימים
db.code_snippets.createIndex({sort_field: 1})

// 3. שימוש ב-collation לאופטימיזציה
db.code_snippets.createIndex({sort_field: 1}, {collation: {locale: "en", strength: 2}})

// 4. בדיקת ביצועים עם explain
db.code_snippets.explain("executionStats").aggregate(pipeline)

ג. אופטימיזציות ברמת ה-Application
# 1. פיצול pipeline למספר שלבים
def optimized_aggregate(collection, pipeline):
    # שלב ראשון - סינון ראשוני
    filter_stage = [stage for stage in pipeline if stage.get('$match')]
    if filter_stage:
        filtered = list(collection.aggregate(filter_stage, allowDiskUse=True))

    # שלב שני - מיון עם allowDiskUse
    sort_stage = [stage for stage in pipeline if stage.get('$sort')]
    if sort_stage:
        return list(collection.aggregate(
            filter_stage + sort_stage,
            allowDiskUse=True
        ))
    return list(collection.aggregate(pipeline, allowDiskUse=True))

# 2. שימוש ב-batch processing
def batch_aggregate(collection, pipeline, batch_size=1000):
    cursor = collection.aggregate(pipeline, allowDiskUse=True, batchSize=batch_size)
    while True:
        batch = list(itertools.islice(cursor, batch_size))
        if not batch:
            break
        yield batch

3. אסטרטגיית פתרון רב-שלבית
שלב 1: איתור מיידי של הבעיה
# הוספת middleware לזיהוי קריאות בעייתיות
@app.after_request
def log_aggregation_calls(response):
    if hasattr(g, 'mongo_aggregations'):
        for call in g.mongo_aggregations:
            if not call.get('allow_disk_use'):
                logger.warning(
                    f"Unsafe aggregation detected: {call['collection']}.{call['method']} "
                    f"at {call['file']}:{call['line']}"
                )
    return response

# מונקי-פאצ'ינג של pymongo
original_aggregate = pymongo.collection.Collection.aggregate

def patched_aggregate(self, pipeline, **kwargs):
    frame = inspect.currentframe().f_back
    caller_info = f"{frame.f_code.co_filename}:{frame.f_lineno}"

    if not kwargs.get('allowDiskUse'):
        logger.warning(f"Unsafe aggregate call at {caller_info}")
        kwargs['allowDiskUse'] = True

    if not hasattr(g, 'mongo_aggregations'):
        g.mongo_aggregations = []
    g.mongo_aggregations.append({
        'collection': self.name,
        'method': 'aggregate',
        'allow_disk_use': kwargs.get('allowDiskUse', False),
        'file': frame.f_code.co_filename,
        'line': frame.f_lineno
    })

    return original_aggregate(self, pipeline, **kwargs)

pymongo.collection.Collection.aggregate = patched_aggregate

שלב 2: תיקון מקיף של הקוד
# 1. חיפוש מתקדם של כל קריאות aggregate
grep -r --include="*.py" -n -A 2 -B 2 "aggregate(" . | grep -v "allowDiskUse"

# 2. יצירת wrapper function מרכזי
class MongoDBWrapper:
    @staticmethod
    def safe_aggregate(collection, pipeline, **kwargs):
        """
        Safe wrapper for MongoDB aggregate operations
        Automatically enables allowDiskUse and adds monitoring
        """
        kwargs.setdefault('allowDiskUse', True)

        # הוספת metadata לניטור
        frame = inspect.currentframe().f_back
        caller_info = f"{frame.f_code.co_filename}:{frame.f_lineno}"

        try:
            start_time = time.time()
            result = list(collection.aggregate(pipeline, **kwargs))
            duration = time.time() - start_time

            # לוגינג של פעולות ארוכות
            if duration > 1.0:
                logger.info(
                    f"Aggregation completed in {duration:.2f}s at {caller_info}. "
                    f"Pipeline: {json.dumps(pipeline, default=str)}"
                )

            return result
        except Exception as e:
            logger.error(
                f"Aggregation failed at {caller_info}: {str(e)}. "
                f"Pipeline: {json.dumps(pipeline, default=str)}"
            )
            raise

# 3. עדכון כל הקריאות בקוד
find . -name "*.py" -exec sed -i 's/\.aggregate(\(.*\))/.safe_aggregate(\1)/g' {} \;

שלב 3: ניטור ומניעה ארוכת טווח
# 1. הוספת ניטור ל-MongoDB
def setup_mongo_monitoring(db):
    def monitor():
        while True:
            try:
                # בדיקת פעולות ארוכות
                current_ops = db.admin.command("currentOp")
                for op in current_ops.get('inprog', []):
                    if op.get('command', {}).get('aggregate'):
                        if op.get('secs_running', 0) > 30:
                            logger.warning(
                                f"Long-running aggregation: {op.get('command')}. "
                                f"Running for {op['secs_running']}s"
                            )

                # בדיקת שימוש בזיכרון
                server_status = db.admin.command("serverStatus")
                mem_usage = server_status.get('mem', {})
                if mem_usage.get('resident') > 8000:  # 8GB
                    logger.warning(f"High memory usage: {mem_usage}")

                time.sleep(60)
            except Exception as e:
                logger.error(f"Monitoring failed: {e}")
                time.sleep(30)

    threading.Thread(target=monitor, daemon=True).start()

# 2. הוספת בדיקות אוטומטיות
@pytest.fixture
def mongo_client():
    client = MongoClient(os.getenv('MONGO_URI'))
    yield client
    client.close()

def test_aggregate_operations(mongo_client):
    db = mongo_client.get_database()

    # בדיקה שכל קריאות aggregate משתמשות ב-allowDiskUse
    for collection_name in db.list_collection_names():
        collection = db[collection_name]
        try:
            # בדיקה עם pipeline פשוט
            list(collection.aggregate([{"$match": {}}], allowDiskUse=True))
        except Exception as e:
            if "allowDiskUse" in str(e):
                pytest.fail(f"Collection {collection_name} has unsafe aggregate operations")

    # בדיקה ספציפית ל-code_snippets
    try:
        list(db.code_snippets.aggregate([{"$sort": {"_id": 1}}], allowDiskUse=True))
    except Exception as e:
        pytest.fail(f"code_snippets aggregate test failed: {e}")

סיכום ומסקנות
1. סיכום הבעיה והפתרונות
היבט	בעיה	פתרון
Deploy לא עקבי	חלק מה-instances רצות עם קוד ישן	איתור וטיפול בכל instances, איפוס מטמון
קריאות aggregate לא בטוחות	קריאות ללא allowDiskUse	wrapper function מרכזי, מונקי-פאצ'ינג
ניטור לקוי	קושי באיתור הבעיה	הוספת logging מפורט, ניטור בזמן אמת
אופטימיזציה	שאילתות לא יעילות	ניתוח עם explain(), יצירת אינדקסים
מניעה עתידית	חזרה של הבעיה	בדיקות אוטומטיות, CI/CD משופר
2. צעדים מיידיים לביצוע

אימות deploy מלא:

# בדיקת כל instances
for instance in $(kubectl get pods -l app=your-app -o jsonpath='{.items[*].metadata.name}'); do
  kubectl exec $instance -- curl -s http://localhost/healthz | jq '.static_version'
done

# איפוס כל ה-pods
kubectl rollout restart deployment/your-app


הטמעת פתרון ה-wrapper:

# הוספה לקובץ mongo_utils.py
class MongoDB:
    @staticmethod
    def aggregate(collection, pipeline, **kwargs):
        kwargs.setdefault('allowDiskUse', True)
        return collection.aggregate(pipeline, **kwargs)


הוספת ניטור:

# הוספה ל-application startup
setup_mongo_monitoring(db)


בדיקת אינדקסים:

// הרצת ב-mongo shell
db.code_snippets.getIndexes()
db.code_snippets.createIndex({field_used_in_sort: 1})

3. המלצות ארוכות טווח

שיפור תהליך ה-CI/CD:

הוספת בדיקות אוטומטיות ל-allowDiskUse
בדיקת כל instances לאחר deploy
איפוס מטמון כחלק מתהליך ה-deploy

ניטור מתקדם:

הטמעת מערכת ניטור כמו Prometheus + Grafana
הגדרת alerts על פעולות aggregation ארוכות
ניטור שימוש בזיכרון של MongoDB

אופטימיזציה של ה-Database:

סקירה תקופתית של אינדקסים
ניתוח שאילתות עם explain()
שיקול של שימוש ב-Time Series Collections אם רלוונטי

שיפור הקוד:

יצירת ספריית לקוח מונגו מותאמת אישית
הטמעת caching לשאילתות תכופות
שימוש ב-batch processing לשאילתות גדולות
4. מסקנה סופית

הבעיה הנוכחית היא שילוב של:

בעיית deploy לא מלא שגורמת לחלק מה-instances לרוץ עם קוד ישן
חוסר עקביות בקריאות ל-MongoDB aggregate
חוסר בניטור ובאופטימיזציה של השאילתות

הפתרון המומלץ הוא רב-שלבי:

מיידי: איתור וטיפול בכל instances עם קוד ישן, הטמעת wrapper function
בינוני טווח: הוספת ניטור מקיף, בדיקות אוטומטיות, אופטימיזציה של שאילתות
ארוך טווח: שיפור תהליך ה-CI/CD, הטמעת ספריית לקוח מונגו מותאמת, ניטור מתקדם

גישה זו תבטיח לא רק פתרון לבעיה הנוכחית, אלא גם מניעה של בעיות דומות בעתיד. ```

---

### Grok (תשובה #9)

שגיאה: Error code: 403 - {'code': 'The caller does not have permission to execute the specified operation', 'error': "Your newly created team doesn't have any credits or licenses yet. You can purchase those on https://console.x.ai/team/f006bbf3-c135-4060-bfb9-1dfd986c2cd5."}

---

### DeepSeek (תשובה #11)

שגיאה: Error code: 402 - {'error': {'message': 'Insufficient Balance', 'type': 'unknown_error', 'param': None, 'code': 'invalid_request_error'}}

---

### Perplexity (תשובה #13)

ניתוח מקיף ומשודרג: פתרון בעיית Deploy לא עקבי + MongoDB Sort Memory Limit
סיכום הנקודות החזקות מהתשובות הקודמות
Claude: ניתוח ראשוני מעולה
חוזקות: זיהוי מדויק של בעיות deploy (cache, load balancer, restarts), חיפוש קוד מעשי, wrapper function פשוט
תרומה: צעדים קונקרטיים לאימות deploy + logging מפורט
GPT: דגש על תהליכים ארוכי טווח
חוזקות: שיפור CI/CD, ניטור alerting, אופטימיזציה של DB
תרומה: חשיבה אסטרטגית למניעה עתידית
Mistral: הפתרון הטכני המקיף ביותר
חוזקות: טבלאות תרחישים, monkey-patching, בדיקות מתקדמות, monitoring thread, pytest fixtures
תרומה: פתרונות production-ready עם קוד מלא
תובנות חדשות + ניתוח מעמיק שלא כוסו בתשובות הקודמות
1. השגיאה הספציפית: 33MB ≠ 100MB ברירת מחדל

הלוג מראה 33554432 bytes (32MB), לא 104857600 bytes (100MB) המוכר. זה מצביע על:

internalQueryMaxBlockingSortMemoryUsageBytes = 32MB (ברירת מחדל חדשה?)


בדיקה מיידית נדרשת:

// ב-Mongo shell
db.runCommand({getParameter: 1, "internalQueryMaxBlockingSortMemoryUsageBytes": 1})
db.adminCommand({getParameter: 1, internalQueryExecMaxBlockingSortBytes: 1})

2. הנתיב /files + שורה 11639: רמז מכריע

השגיאה מגיעה משורה ספציפית בקוד ישן שלא אמורה להתקיים. זה מצביע על:

1. Bytecode cache (pyc) לא עודכן
2. Multiple Python processes עם קוד שונה
3. Import cycle שגורם לטעינת מודול ישן


בדיקה קריטית:

# בדיקת קבצי .pyc ישנים
find . -name "*.pyc" -o -name "__pycache__" -exec ls -la {} \; | head -20

# מחיקת כל caches
find . -name "*.pyc" -delete
find . -name "__pycache__" -type d -exec rm -rf {} + 

# בדיקת processes ו-loaded modules
python -c "
import sys, gc
for mod in gc.get_objects():
    if isinstance(mod, dict) and '__file__' in mod:
        print(mod['__file__'])
" | grep code_snippets

3. Render.com ספציפי: Blue-Green Deploy Issues

התאריך בלוג (2026-02-11) + /opt/render/project/ מצביע על Render.com. בעיות נפוצות:

- Blue-Green deployment: חלק מה-traffic עדיין מגיע ל-instance ישן
- Build cache לא נוקה בין deploys
- Static files deployment לא מסונכרן עם app restart


פתרון Render ספציפי:

# 1. Manual deploy עם no-cache
render deploy --no-cache

# 2. בדיקת service status
render services list --status

# 3. Force restart
curl -X POST https://api.render.com/v1/services/{SERVICE_ID}/suspend \
  -H "Authorization: Bearer {TOKEN}"
curl -X POST https://api.render.com/v1/services/{SERVICE_ID}/resume \
  -H "Authorization: Bearer {TOKEN}"

4. Pipeline Analysis: למה זה קורה בדיוק ב-/files?

השגיאה ב-db.code_snippets.aggregate(pipeline) → pipeline מכיל $sort על dataset גדול.

סביר שזה search/pagination עם sort על text field ללא index


אופטימיזציה קריטית:

# 1. בדיקת pipeline אמיתי
@app.route('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/debug/pipeline')
def debug_pipeline():
    # הריץ את אותו pipeline שגורם לקריסה
    pipeline = [...]  # מהקוד ב-/files
    explain = db.command('explain', {
        'aggregate': 'code_snippets',
        'pipeline': pipeline,
        'cursor': {}
    })
    return jsonify(explain)

# 2. אינדקס חובה
db.code_snippets.createIndex({"search_field": "text", "created_at": -1})

אסטרטגיית פתרון 4-שלבים: מיידי → ארוך טווח
שלב 1: איתור מיידי (30 דקות)
# 1. ניקוי מלא של caches
rm -rf **/__pycache__ **/
find . -name "*.pyc" -delete

# 2. בדיקת כל instances ב-Render
curl https://your-app.onrender.com/healthz | jq
# אם יש multiple regions/services - בדוק את כולם

# 3. Force restart דרך Render dashboard או CLI
render deploys create --service your-service --branch main --no-cache

שלב 2: Monkey-Patch + Wrapper (מיידי + בטוח)
# mongo_safe.py - הטמעה גלובלית
import functools
import inspect
import logging
from flask import g
from pymongo import collection

logger = logging.getLogger(__name__)

def safe_aggregate_patch():
    """Monkey patch לכל aggregate calls"""
    original_aggregate = collection.Collection.aggregate
    
    @functools.wraps(original_aggregate)
    def patched_aggregate(self, pipeline, **kwargs):
        caller = inspect.currentframe().f_back
        caller_info = f"{caller.f_code.co_filename}:{caller.f_lineno}"
        
        # Force allowDiskUse + logging
        kwargs['allowDiskUse'] = True
        
        if not hasattr(g, 'unsafe_aggregates'):
            g.unsafe_aggregates = []
        
        # Log אם לא היה allowDiskUse במקור
        if 'allowDiskUse' not in kwargs:
            g.unsafe_aggregates.append({
                'file': caller.f_code.co_filename,
                'line': caller.f_lineno,
                'pipeline': pipeline[:3]  # ראש 3 stages בלבד
            })
            logger.warning(f"Fixed unsafe aggregate at {caller_info}")
        
        return original_aggregate(self, pipeline, **kwargs)
    
    collection.Collection.aggregate = patched_aggregate

# ב-app startup
safe_aggregate_patch()

שלב 3: אופטימיזציה + Monitoring (יום)
# monitoring.py
import threading
import time
from flask import current_app

def start_mongo_monitoring(app):
    def monitor():
        db = current_app.db
        
        while True:
            try:
                # Long running ops
                ops = db.admin.command('currentOp', {'aggregate': {'$exists': True}})
                for op in ops.get('inprog', []):
                    secs = op.get('secs_running', 0)
                    if secs > 10:
                        logger.warning(f"Long agg: {secs}s - {op.get('command', {})}")
                
                time.sleep(30)
            except Exception as e:
                logger.error(f"Monitor error: {e}")
                time.sleep(60)
    
    threading.Thread(target=monitor, daemon=True).start()

# ב-app startup
start_mongo_monitoring(app)

שלב 4: CI/CD + Prevention (שבוע)
# .github/workflows/deploy.yml
name: Deploy with Safety Checks
jobs:
  deploy:
    steps:
      - uses: actions/checkout@v3
      - name: Check aggregate safety
        run: |
          UNSAFE=$(grep -r "aggregate(" . --include="*.py" | grep -v "allowDiskUse")
          if [ -n "$UNSAFE" ]; then
            echo "❌ Unsafe aggregates found:"
            echo "$UNSAFE"
            exit 1
          fi
      
      - name: Clear build cache
        run: render deploy --no-cache

מסקנה + צעדים מיידיים (העתק-הדבק)
היום (עכשיו):
1. rm -rf **/__pycache__ **/
2. find . -name "*.pyc" -delete
3. render deploys create --service your-service --no-cache
4. הטמע monkey-patch מהשלב 2

הסיבה האמיתית (90% הסתברות):

Render.com blue-green deployment + Python bytecode cache. חלק מה-requests מגיעים ל-instance ישן עם קוד .pyc לא מעודכן.

תוצאה צפויה:

✅ קריסות נעלמות תוך שעה
✅ ניטור אוטומטי למניעת חזרה
✅ CI/CD בטוח ל-deploy הבא

התשובה המשודרגת משלבת: כל החוזקות הקודמות + Render-specific + bytecode debugging + pipeline analysis + production-ready code.

---

### Qwen (תשובה #15)

שגיאה: Error code: 403 - {'error': {'message': 'Access to model denied. Please make sure you are eligible for using the model.', 'type': 'AccessDenied.Unpurchased', 'param': None, 'code': 'AccessDenied.Unpurchased'}, 'id': 'chatcmpl-0f21f7ae-7595-957d-bfa8-1e39d4c2ad20', 'request_id': '0f21f7ae-7595-957d-bfa8-1e39d4c2ad20'}

---

### Manus (תשובה #17)

שגיאה: Not Found

---

### Gemini (תשובה #19)

שגיאה: 403 Your API key was reported as leaked. Please use another API key.

---