Привязка инфобазы к ветке хранится под refs/heads/<ветка> — ключом, который читает EDT (#684) - #705
Conversation
…ds (#684) set_branch_infobase and create_git_branch wrote a binding under the bare short branch name, but EDT keys a branch context by the full ref: GitRepositoryAssociationContextManager returns of(repository.getFullBranch()), and InfobaseAssociationContext compares the strings literally. Such a binding never became the current context: EDT did not pick it up on checkout, and update_database / get_applications never saw it. A shared helper, utils/git/BranchContexts, maps a branch input - its short name or its refs/heads/... ref - to the context EDT reads, and refuses a remote-tracking ref, any other ref, a blank or an invalid name before anything is touched. Both writers attach, set the default and read back under refs/heads/<branch>. list_git_branches shows a branch context by its branch name and marks any other key; a binding an older version wrote under the short name is listed as a legacy key, and a detach removes it and says so. Nothing is migrated automatically. EDT records a default only for an infobase that is also bound to the checked-out branch. A default it refuses after a successful attach no longer turns the done attach into an error: the attach stands and the answer's message says why and what to do. A platform failure storing the default is reported there without that advice, and logged. set_branch_infobase declares the message it returns in its output schema. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0174zH13nscxbTgBU4YfXcXK
E2E Test Results (EDT 2026.2) 4 files ±0 4 suites ±0 1h 12m 26s ⏱️ -3s Results for commit 6520b91. ± Comparison against base commit d62c416. This pull request skips 2 tests.♻️ This comment has been updated with latest results. |
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Codex Review: Didn't find any major issues. Breezy! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
2 participants
Closes #684.
Что было
set_branch_infobaseиcreate_git_branchписали привязку под коротким именем ветки (InfobaseAssociationContext.of(branch)), а EDT ключует контекст ветки ПОЛНЫМ ref:GitRepositoryAssociationContextManager.getвозвращаетof(repository.getFullBranch()),GitBranchToContextConverterстроитof("refs/heads/" + name), аInfobaseAssociationContext.equalsсравнивает строки буквально. Поэтому такая привязка никогда не становилась текущим контекстом: EDT не подхватывала её при checkout, аupdate_databaseиget_applicationsеё не видели.list_git_branchesпри этом печатал контексты сырыми строками, и разница была не видна.Что изменилось
utils/git/BranchContexts. Он переводит вход — короткое имя (feature/x) или полный ref (refs/heads/feature/x) — в контекстrefs/heads/<ветка>, тот самый, что читает EDT. Remote-tracking ref, любой другой ref, пустое и невалидное для git имя отклоняются с actionable-текстом до любых обращений к репозиторию. Внутренний конвертер EDT не используется, внутренних классов нет.set_branch_infobaseпривязывает, ставит умолчание и делает read-back подrefs/heads/<ветка>. Detach сначала ищет привязку под полным ref, затем под старым коротким ключом. Если снята легаси-запись, ответ говорит об этом вmessage. Если нет ни той, ни другой, ответ — прежний actionable «not bound», где теперь названы оба ключа.create_git_branchприapplicationIdпривязывает к созданному ref (refs/heads/<ветка>).list_git_branchesпоказывает контекст ветки коротким именем. Любой другой ключ выводится как есть, с пометкой: легаси-ключ (legacy short key - matches no branch, EDT never reads it; detach it with set_branch_infobase), не-веточный ref или коммит detached HEAD.setDefaultInfobaseпроверяетgetAssociation(IProject), а не переданный контекст, и бросаетIllegalArgumentException. Это сверено по байткоду 2026.2. Раньше такой отказ превращал уже состоявшийся attach в ошибку. Теперь attach остаётся, аmessageобъясняет причину и даёт совет (выгрузить ветку и повторить сsetDefault). Сбой самой платформы (InfobaseAssociationException) тоже идёт вmessage, но без совета про выгрузку, и логируется, как раньше.outputSchemaуset_branch_infobaseобъявлено необязательноеmessage: инструмент возвращает его в двух описанных случаях. Golden против master — ровно эти 3 строки. Описания иinputSchemaне менялись. Гайды трёх инструментов описывают настоящий контракт, их копии вdocs/toolsдословные, чужой дрейф генератора в эти страницы не взят.Следствие — объявляю явно
Привязки, сделанные этими двумя инструментами, теперь видит сама EDT при checkout, а также
get_applicationsи проверка из #686 вupdate_database(отказ, если инфобаза цели не привязана к текущей ветке). До этого PR привязка черезset_branch_infobaseэтой проверке не помогала.Граница
list_git_branchesс пометкой и снимаются через detach. Чтобы привязка заработала, базу нужно привязать заново.create_infobaseна git-проекте привязывает базу к ПУСТОМУ контексту. EDT же читает контекст выгруженной ветки, поэтому созданная база не появляется вget_applications. Это и есть create_infobase / delete_infobase use the default infobase association instead of the current Git branch's, so the new infobase never appears in get_applications #656.applicationIdвидит только приложения текущего контекста, а значит любая резолвимая база уже привязана к выгруженной ветке. Отказ доказан юнитами и мутациями. Живьём проверен обратный случай: база уже привязана к выгруженнойmaster, attach к НЕвыгруженной ветке сsetDefault=trueпрошёл без отказа и безmessage.Доказательства
Юниты: новый
BranchContextsTestи расширенныеSetBranchInfobaseToolTest,CreateGitBranchToolTest,ListGitBranchesToolTest. Что они проверяют:refs/heads/...и никогда под коротким ключом (пин отсутствия);/и кириллицей.Мутации — 29, каждая роняет свои пины. Среди них:
refs/heads/;refs/remotes/...;messageпропал изoutputSchema.Восстановление по sha256,
target/тестового бандла чистится перед каждым прогоном.Сборка: BUILD SUCCESS, 8807 юнит-тестов, 0 падений.
Стенд (EDT 2026.2), anti-stale: jar
202609221454заменён на202610021509; маркерBranchContexts(0 → есть) проверен при положительном контроле; рантайм-проба — новый текст гайда вget_tool_guide.list_git_branchesпечатал сыройrefs/heads/master. Attach по короткому имени и затем detach поrefs/heads/e2e-684-binding-probeдали отказis not bound to branch context 'refs/heads/e2e-684-binding-probe': старый писатель клал короткий ключ, а на диске появился каталог контекстаe2e-684-legacy-probe/.list_git_branches5/5,set_branch_infobase6/6,tools_list2/2,fixture clean: True. Легаси-ключ, записанный старым jar, показан с пометкой и снят detach-ем с сообщением. Контекст хранится ровно подrefs/heads/<ветка>, без удвоения префикса.refs/heads/<ветка>. Приложение появилось вget_applicationsлишь после того, как привязка оказалась в контекстеrefs/heads/master. Привязки под(default)и под коротким ключом EDT не видела.e2e в
test_list_git_branches.py:refs/heads/;EDT_MCP_LIVE_INFOBASE=1): attach по короткому имени, затем список, затем detach по ПОЛНОМУ ref. Detach по полному ref добавлен, чтобы тест различал запись по короткому ключу. Честная оговорка: усиленный тест целиком на старом jar не прогонялся. На старом jar он падал раньше, на сыромrefs/heads/master, а шаг detach по полному ref проверен там отдельным вызовом (отказ выше).get_applications. На стенде его пришлось создать вручную, из-за create_infobase / delete_infobase use the default infobase association instead of the current Git branch's, so the new infobase never appears in get_applications #656: привязку положили в контекстrefs/heads/masterпри остановленном стенде и после прогона удалили.Ревью до push: гейт корректности нашёл настоящий дефект — отказ EDT в default ломал успешный attach; дефект исправлен. Повторный гейт дал SHIP, независимая сверка доказательств стенда — CONFIRMED. PR-бот codex сейчас без квоты; ревью запрошу, как только она вернётся.
🤖 Generated with Claude Code
https://claude.ai/code/session_0174zH13nscxbTgBU4YfXcXK