Параллельные пчёлы обвиняют друг друга: измерение идёт по общему дереву

[gHashTag]

Часть #1090.

Доказано прогоном

Две пчелы работали одновременно с непересекающимися границами. Каждую обвинили в записях другой:

06:56:18 queen.observer.outOfBounds  issue=#1098
   paths = rings/SR-02/ChatViewModel.swift          <- файл задачи #1112
07:00:03 queen.observer.outOfBounds  issue=#1112
   paths = BR-OUTPUT/ChatPanelView.swift, tests/swift/ChatSSEEndToEndTest.swift   <- файлы #1098

Ни одна границу не нарушила. Обе получили выговор.

Причина

QueenBranchCommitter.changedPaths спрашивает git, что изменилось в общем рабочем дереве относительно снимка, сделанного при старте пчелы. Пока пчела одна, ответ — её работа. Как только их две, в ответ попадает всё, что успела написать соседка.

Это третье ложное обвинение подряд после #1102 и #1114, и оно опаснее обоих: те были постоянными и потому заметными, это появляется только при параллельной работе — то есть ровно тогда, когда система делает то, ради чего построена.

Коммит в ветку при этом фильтруется по границе (в ветку #1112 попал только её файл), так что чужая работа в чужую ветку не утекла. Врёт именно наблюдатель.

Готово, когда

• Пчела, писавшая только внутри своей границы, не получает outOfBounds при работающей рядом второй пчеле.
• Настоящий выход за границу по-прежнему виден, в том числе когда параллельно работает вторая пчела: проверка ломается, если сузить измерение до «ничего не замечать».
• Доказано прогоном двух одновременных задач, а не рассуждением.

Границы

rings/SR-02/QueenBranchCommitter.swift и rings/SR-02/ChatViewModel.swift.

[gHashTag]

Механизм написан и не работает: пчела добавила с фильтром по границе, но оба места вызова в зовут её без , а по умолчанию это пустой список — фильтр не включается никогда.

Проверено прогоном двух одновременных пчёл уже после сборки с правкой:

08:03:22 outOfBounds #1117 -> BR-OUTPUT/ChatPanelView.swift, tests/swift/ChatSSEEndToEndTest.swift

Это файлы задачи #1118. Обвинение осталось.

Третий раз та же форма, что в #1111: пчела меняет свой файл, вызывающий живёт в границе другой, и в цикле пчелы ничего не собирает пару.

Отдельно стоит записать компромисс, который пчела задокументировала честно: фильтрация по границе делает измеренные записи слепыми к настоящему выходу за границу этой пчелы. Остаются имена инструментов, а они не видят записи через shell — ровно та дыра, ради которой измерение и вводили. То есть починка ложных обвинений ослабляет проверку, и это надо решить, а не проглотить.

[gHashTag]

Поправка к предыдущему комментарию — он отправился обрезанным, мой шелл съел куски в обратных кавычках.

Механизм был написан и не работал. Пчела добавила в changedPaths параметр ownedPaths с фильтром по границе, но оба места вызова в ChatViewModel.swift звали её без него, а по умолчанию это пустой список — фильтр не включался никогда.

Проверено прогоном двух одновременных пчёл уже после сборки с той правкой:

08:03:22 outOfBounds #1117 -> BR-OUTPUT/ChatPanelView.swift, tests/swift/ChatSSEEndToEndTest.swift

Это файлы задачи #1118. Обвинение осталось. Третий раз та же форма, что в #1111: пчела меняет свой файл, вызывающий живёт в границе другой, и в цикле пчелы ничего не собирает пару.

Отдельно — компромисс, который пчела задокументировала честно: фильтрация по границе делает измеренные записи слепыми к настоящему выходу за границу этой же пчелы. Остаются имена инструментов, а они не видят записи через shell — ровно та дыра, ради которой измерение и вводили. Это надо решить, а не проглотить.

[gHashTag]

Сделано и доказано двумя одновременными пчёлами — тем же способом, каким дефект был вскрыт.

Было, на каждом параллельном прогоне: #1098 обвиняли в файле #1112, #1112 — в файлах #1098. Стало: две пчелы, каждая пишет свой файл, ноль обвинений, в каждую ветку попал только её файл.

Первая правка была инертной: параметр добавили в свой файл, оба места вызова живут в чужом, фильтр по умолчанию выключен и не срабатывал ни разу. Третий раз та же форма, что в #1111.

Настоящее нарушение по-прежнему ловится — кассета notices a write outside the boundary проходит.

Компромисс не проглочен: фильтрация по границе делает измеренные записи слепыми к настоящему выходу за границу этой же пчелы, остаются имена инструментов, а они не видят записи через shell. Это открытый вопрос.