Перестала работать отладка приложения на удаленной ИБ

Groyzer commented 5 months ago

Описание ошибки

При попытке запуска отладки приложения на удаленной ИБ ничего не происходит. Ошибка воспроизводится только в случае, когда проект и ИБ не синхронизированы. В случае, если проект и ИБ синхронизированы или требуется только инкрементальная сборка, сеанс отладки запускается. Выходит, что в текущей версии для запуска удаленной отладки необходима обязательная синхронизация проекта и ИБ. Не редко возникают ситуации, когда необходимо запустить отладку минуя довольно долгий процесс синхронизации, т.к. проект и удаленная ИБ идентичны.

Как воспроизвести

Импортируем проект из гит
Добавляем приложение на удаленной ИБ
Важно! Не выполняем полную загрузку
Запускаем отладку без обновления удаленной ИБ С конфигурацией отладки "по умолчанию"
На вопрос об обновлении отвечаем "Нет"
Отладка не запускается, в логах нет информации об ошибке

Скриншоты

No response

Ожидаемое поведение

Ожидается, что независимо от состояния синхронизации будет запущен сеанс отладки, как это было в предыдущих версиях.

Лог рабочей области

.log trace.log

Версия 1С:EDT

1CEDT (2023.3.5+10)

Операционная система

Windows

Версия платформы 1С:Предприятие 8

1С Предприятие x86-64 (8.3.23.2040)

Установленные плагины

No response

Дополнительная информация

No response

JaneGlass73 commented 5 months ago

Для нас это критично.

nikolay-martynov commented 4 months ago

@Groyzer @JaneGlass73 Алексей, Евгения, здравствуйте. В 2024.1 в журнале при этом можно найти вот такую запись:

!ENTRY com._1c.g5.v8.dt.launching.core 8 0 2024-06-18 17:17:33.492
!MESSAGE Старт отладки был отменён пользователем.

Действительно, у системы нет никаких сведений о том, что там в информационной базе. Она может быть пустой. Там может быть какая-то другая конфигурация. А может и та же самая, что и в проекте, но с неучтёнными изменениями. Одно дело, когда ранее информационная база была синхронизирована с проектом. Тогда, действительно, система позволяет пропустить обновление конфигурации информационной базы. Но даже в этом случае система проверяет, что конфигурация информационной базы не была изменена. Если была, то система предложит либо импортировать, либо перезаписать эти изменения. Попытка отлаживаться в состоянии, когда состояние проекта не соответствует конфигурации информационной базы с высокой вероятностью приведёт к различным ошибкам:

не будут устанавливаться точки останова
не будут срабатывать точки останова
система будет неверно переходить по строкам и заходить в процедуры
система будет отображать неверный набор и значения переменных

Скажите пожалуйста, почему вы считаете, что нужно отлаживаться, когда проект и конфигурация информационной базы вообще никак не синхронизированы?

JaneGlass73 commented 4 months ago

@nikolay-martynov Здравствуйте! Всё просто. База (ERP, УХ) у нас собрана в сборочном конвейере, на сервере по данным гита, допустим с ветки dev/108, коммит ИД f1846c413906a7c122df2688930fd90eaab710a7. Нужно срочно разобрать ошибку в этой ветке разработчику, он просто берёт, копирует себе эту базу, это отнимает максимум 20 минут (СУБД бэкап), чтобы всё развернуть. Соответственно разработчик актуализирует свой клон хранилища с удалённой веткой и переключаясь на неё, присоединяет базу в панели "Приложения". Они соответствуют, хотя EDT об этом не знает, и не может узнать, не сделав полной сборки. Разработчику, чтобы прошагать код в отладчике не нужно её повторно собирать, она уже есть с нужным тестовым примером. Мы даже зачастую и не копировали эту базу, а просто извлекали нужный коммит, добавляли в "Приложения" базу на сервере, которая была собрана, и уже через 5 минут могли разобрать проблему, и ничего из того, что Вы перечислили никогда не, ни разу не происходило, ну если быть совсем честной, то да, конечно было, когда разработчик по ошибке извлёк не ту ветку, не тот коммит, но это вопрос решался в течении нескольких минут, и после того как нужный коммит был извлечён можно было корректно проводить отладку. Мы просто делали так, как описал Алексей - отказывались от сборки. Сейчас же , штатно, чтобы начать отладку мне нужно полностью пересобрать базу, хотя получится конфигурация один в один, НО теперь представьте, что это не пустая файловая база, а база ОЭ, в которую проведена миграция остатков, в которой уже пользователи начали вести учёт, и которая весит за 100Гб, там только реорганизация (которая будет тупо перегонять из одной таблицы в точно такую же данные, но у которой будут другие configVersion в CDI.xml) будет длиться час. если не больше. Разницу ощутите, пожалуйста, 5 минут и 120 минут... Я лишь просто прошу об одном, раз вы не можете проверить соответствует ли присоединённая ИБ текущему коммиту, с которого она собиралась, то оставьте хотя бы возможность разработчику и дальше самому решать вопрос - нужно ему её пересобрать или нет. Например, мы используем ПП, который при каждой сборке тестовой ИБ в пайпе фиксирует для этой базы commit id: Поэтому сейчас эта проблема нам очень мешает перейти на новый релиз EDT (в котором есть много того, чего мы ждали). Мы конечно знаем способ как обойти, мы всё равно будем делать это способом, предложенным @mrshadow300373 ещё 3 года назад (спасибо Вам (без сарказма) что не меняете алгоритм синхронизации ИБ с веткой), но и это отнимает лишних 20 минут. Но мы точное не хотим тратить вхолостую 2 часа разработчика на бессмысленную сборку. В пайпе у нас полная сборка идёт через ibcmd что позволяет нам собрать нужную CF(CFU) за 35 минут против 2 часов в EDT. Для клиент серверных баз автономный сервер в EDT сейчас не поддерживается. Я понимаю причины по которым вы сделали так как сделали, потому что куча балбесов, которые делают так, как не нужно вас засыпали, возможно, сообщениями об ошибках, когда отладчик начинал шагать по пустым строкам. Вы защитились от них таким образом. Но, почему нормальные то должны страдать, которые точно понимают что делают? Возможно Вы скажете, что ошибки нужно уметь воспроизводить на другой базе. Да, конечно, это возможно, но на это уходит ещё больше времени, чтобы сделать контрольный пример. Сами же просите клон хранилища, воркспейса, чтобы быстро воспроизвести проблему... Надеюсь мои аргументы будут достаточны. Простите, пожалуйста, возможно немного эмоционально получилось, нам это и вправду критично. Мы никак не можем инициировать перевод конфигурации (EDT Translation tool) - ошибка #1151 в новом релизе исправлена.

nikolay-martynov commented 4 months ago

@JaneGlass73 Евгения, благодарю за подробное объяснение.

nikolay-martynov commented 4 months ago

В версии 2024.1 можно будет запускать отладку пропуская обновление информационной базы.

1C-Company / 1c-edt-issues