Synchronize programming language field name across project - #17
Merged
amirbiron merged 1 commit intoAug 6, 2025
Conversation
… files Co-authored-by: amirbiron <amirbiron@gmail.com>
Contributor
|
Cursor Agent can help with this pull request. Just |
amirbiron
marked this pull request as ready for review
August 6, 2025 06:35
amirbiron
deleted the
cursor/synchronize-programming-language-field-name-across-project-9acb
branch
August 6, 2025 06:36
amirbiron
pushed a commit
that referenced
this pull request
Sep 8, 2026
השלמת החצי החסר של סגירת הלולאה. הדפוסים תועדו ב-amir-bug-patterns (PR #17 שם) וקיבלו שורות טריגר ב-INTEGRATION.md, אבל לא כאן — וזה בדיוק המקום שנקרא בזמן המימוש. ה-README של אותו ריפו אומר את זה מפורשות: דפוס בלי טריגר הוא דפוס שלא ייקרא, ושני הצעדים הם צעד אחד. הנוסח זהה מילה במילה לזה שב-INTEGRATION.md, כפי שנדרש שם — עדכון לאחד מחייב עדכון לשני. שני הדפוסים עלו מהעבודה על #3357 ועל ה-PR הזה עצמו: - K15, שומר שמתפרסם לפני הערך שהוא שומר עליו: webapp/app.py:get_db בדק client והחזיר db. תקלת רשת חולפת אחת שיתקה את התהליך עד ריסטארט. - silent-fallback-to-worse-path: נפילה-לאחור על חריגה שהייתה מחזירה את באג 191 השניות בשקט. נתפסה בריוויו לפני שנכתבה. הערת סדר מיזוג: השורות מפנות לשני קבצים שקיימים כרגע רק ב-PR #17 של amir-bug-patterns. ההפניה תתיישב ברגע שהוא ימוזג. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RgnHZBJaH4VhdFFgwYZKLr
amirbiron
added a commit
that referenced
this pull request
Sep 8, 2026
…3361) * perf(search): שליפה מקובצת של הקבצים המתאימים במקום קובץ-קובץ חיפוש "טקסט" של שם קובץ מלא לקח 191.74 שניות. _text_search ו-_function_search החזיקו בלוק זהה מילה במילה ששלף כל קובץ מתאים בשאילתה נפרדת, וכל שליפה כזו היא שלוש קפיצות רשת: GET ל-Redis (@cached עם TTL של 180 שניות), find_one בלי היטלה — כלומר כל ה-code — ואז SETEX. נמדד: 745 קבצים פעילים, 19.6MB. 191.7 חלקי 742 ≈ 258ms לקובץ. ו-limit מוחל רק בסוף, אחרי הסינון והמיון, ולכן הוובאפ ביקש עשר תוצאות והמערכת משכה 745 מסמכים. Repository.get_latest_versions_by_names מחליף את זה בשליפה אחת למנה, בדיוק בצורת האגרגציה של get_user_files פלוס $in. נמדד מול הקלאסטר (executionStats), על הצינור כפי שהקוד באמת בונה אותו: 3 שמות DISTINCT_SCAN, 6 מפתחות, 3 מסמכים, 0ms כל הקורפוס + code DISTINCT_SCAN, 745 מפתחות, 745 מסמכים, 14ms 100 / 250 שמות אותה תוכנית, maxScansToExplodeReached: false מונגו מקפלת את $sort + $group $first ל-$groupByDistinctScan על idx_snippets_latest_version הקיים — בלי מיון חוסם, ובדיוק מסמך אחד לכל שם. אין צורך באינדקס חדש. chunk_size=250 הוא בקרת סיבובי רשת ולא בקרת תוכנית: התוכנית נשארת DISTINCT_SCAN גם ב-250, ו-745 שמות הם ~37KB מול תקרת BSON של 16MB. מכיוון שהעלות הדומיננטית היא הסיבוב עצמו, מנה גדולה עדיפה. הכותרת היא "3 סיבובים במקום 742", לא "14 מילישניות" — את ה-RTT מפרודקשן אי אפשר למדוד מכאן. נפילה-לאחור רק על היעדר המתודה, לעולם לא על חריגה. חמישה קובצי בדיקה מריצים את המסלולים האלה עם דמויות שחושפות get_latest_version בלבד, וזה מצב סטטי וידוע. חריגה אינה: נפילה-לאחור עליה הייתה הופכת כל תקלת מונגו חולפת ל-745 שליפות סדרתיות — מחזירה את הבאג ומחזיקה worker תפוס שלוש דקות. search העוטפת כבר רושמת, פולטת search_error ומחזירה רשימה ריקה, ובוובאפ _safe_search נופל משם ל-$text של מונגו. ההיטלה היא בדיוק שמונת השדות ש-_create_search_result קורא. code נכלל במכוון בניגוד לכלל ה-Smart Projection: _apply_filters נשען על result.content לשלושה מסננים ו-_sort_results על אורכו, ובלעדיו הם היו מסננים על מחרוזת ריקה. snippetEmbedding (~3KB למסמך) כן יורד. שינוי התנהגות שכדאי לזכור: המסלול המקובץ אינו מקושש, ולכן תוצאה שהייתה חוזרת מקאש בן שלוש דקות תגיע מעכשיו טרייה. שיפור בנכונות, לא רגרסיה. 16 בדיקות חדשות, כולן הורצו על העץ הלא-מתוקן קודם: 7 נפלו ואחת עברה (זו של תאימות לדמויות הישנות, שהיא נעילת היקף). ארבע מוטציות מוכיחות שהן מסוגלות ליפול — היפוך סדר $sort/$group, שינוי גודל המנה, נפילה-לאחור על חריגה, והסרת code מההיטלה. בנוסף אומתה נכונות מול מונגו 8.0.4 אמיתי: הגרסה האחרונה חוזרת, קובץ בסל ומשתמש אחר אינם, ו-snippetEmbedding אינו נמשך. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RgnHZBJaH4VhdFFgwYZKLr * fix(db): חוזה ההיטלה של השליפה המקובצת — שלושת ממצאי הריוויו שלושת הממצאים הם פנים אחד: חוזה ההיטלה של get_latest_versions_by_names נכתב רופף יותר מזה של get_user_files, שלוש פונקציות משם באותו קובץ. אף אחד מהם אינו באג בפרודקשן היום — יש קורא ייצור יחיד, והוא מעביר היטלה שכוללת file_name. 1. file_name לא נכפה על היטלת include. המתודה בונה את התשובה לפי doc.get("file_name"), ולכן קורא שיבקש {"_id":1,"code":1} היה מקבל מיפוי ריק — בלי חריגה ובלי לוג. חיפוש שנשבר נראה בדיוק כמו חיפוש בלי תוצאות. 2. בלי היטלה כלל לא נוסף שלב $project, ולכן ברירת המחדל הייתה מסמכים מלאים כולל code ו-snippetEmbedding. זו מתודה ציבורית שנועדה לשלוף מאות מסמכים, וזו בדיוק ההפך מכלל ה-Smart Projection. 3. אין טסט שמאמת שהמנוע מעביר את SEARCH_RESULT_PROJECTION בפועל. הדמה הקליטה רק שמות קבצים. מחיקת הארגומנט הייתה משאירה את כל הקובץ ירוק ומחזירה שליפת מסמכים מלאים בפרודקשן — כלומר מבטלת בשקט חלק מרכזי מהתיקון הקודם. זה החמור מבין השלושה, כי הוא חור בשכבה שאמורה להגן. התיקון אינו עותק שלישי של אותו בלוק: ההיגיון חולץ מ-get_user_files ל-_latest_version_projection_stage, ושתי המתודות משתמשות בו. היום הוא כתוב פעם אחת ומשמש את שתיהן. get_user_files יוצאת מזה בלי שינוי התנהגות — הושוו חמשת מצבי ההיטלה לפני ואחרי, וצורת ה-$project זהה. יש לכך גם טסט קבוע, כי היא במסלול החם של כל מסכי הרשימות וריפקטור שם צריך רשת. הדוקסטרינג אומר עכשיו מה נמדד: explain עם 250 שמות (לא 200), התוכנית נשארה DISTINCT_SCAN ו-maxScansToExplodeReached נשאר false. הסף שמגביל פיצוק $in אינו הכובל כאן כי DISTINCT_SCAN מטפלת בגבולות ישירות. תשע בדיקות חדשות. שלוש נפלו על העץ שלפני התיקון. ארבע מוטציות נתפסו: הסרת כפיית file_name, הסרת מיזוג השדות הכבדים, ברירת מחדל שחוזרת למסמך מלא, ומחיקת הארגומנט projection מקריאת המנוע. אומת מול הקלאסטר שהצינור לא זז: DISTINCT_SCAN, 6 מפתחות, 3 מסמכים, 0ms — כמו קודם. סריקה של 150 קובצי בדיקה: אפס נפילות. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RgnHZBJaH4VhdFFgwYZKLr * docs(claude): שורות טריגר לשני הדפוסים החדשים השלמת החצי החסר של סגירת הלולאה. הדפוסים תועדו ב-amir-bug-patterns (PR #17 שם) וקיבלו שורות טריגר ב-INTEGRATION.md, אבל לא כאן — וזה בדיוק המקום שנקרא בזמן המימוש. ה-README של אותו ריפו אומר את זה מפורשות: דפוס בלי טריגר הוא דפוס שלא ייקרא, ושני הצעדים הם צעד אחד. הנוסח זהה מילה במילה לזה שב-INTEGRATION.md, כפי שנדרש שם — עדכון לאחד מחייב עדכון לשני. שני הדפוסים עלו מהעבודה על #3357 ועל ה-PR הזה עצמו: - K15, שומר שמתפרסם לפני הערך שהוא שומר עליו: webapp/app.py:get_db בדק client והחזיר db. תקלת רשת חולפת אחת שיתקה את התהליך עד ריסטארט. - silent-fallback-to-worse-path: נפילה-לאחור על חריגה שהייתה מחזירה את באג 191 השניות בשקט. נתפסה בריוויו לפני שנכתבה. הערת סדר מיזוג: השורות מפנות לשני קבצים שקיימים כרגע רק ב-PR #17 של amir-bug-patterns. ההפניה תתיישב ברגע שהוא ימוזג. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RgnHZBJaH4VhdFFgwYZKLr * docs(claude): הידוק שורת הטריגר של silent-fallback ממצא ריוויו: הניסוח החריג ערכי ברירת מחדל אך לא זיהוי יכולת סטטי — שהכלל עצמו מכריז עליו כלגיטימי. נוסף "בגלל כשל" ו"לא זיהוי יכולת סטטי". הרוחב של טריגר הוא תכונה ולא באג — תפקידו לומר "לך תקרא", וטריגר צר מדי פירושו שהכלל לא ייקרא כלל. לכן ההידוק מדייק את רגע התפיסה בלי לצמצם אותו. הנוסח זהה מילה במילה ל-INTEGRATION.md שב-amir-bug-patterns, שעודכן באותו סבב. נבדק ב-diff ולא בעין. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RgnHZBJaH4VhdFFgwYZKLr --------- Co-authored-by: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Rename
languagefield toprogramming_languageacross the project to resolve a MongoDB reserved keyword conflict.