Настоящая причина падения integration — не медленный старт, а краш узла:
'plugin_config_exception: Incorrect plugin configuration'. nodeos генерирует
protocol_features/*.json в смонтированный config-каталог; при монтировании
самого workspace эти untracked root-файлы остаются между прогонами на
персистентном раннере и ломают конфиг. Монтируем свежую копию в mktemp-каталог
— узел стартует на чистом конфиге. Заодно sleep 4 (бюджет ожидания ~8 мин).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Self-hosted раннер персистентный: упавший integration оставляет контейнер
с фиксированным именем blockchain, следующий docker run падает exit 125
(Conflict, name already in use). docker rm -f перед стартом — фикс
самовосстанавливающийся, чистит остаток от предыдущего прогона.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
На нагруженном раннере nodeos поднимался >6 мин (cache restore тоже ловил
ETIMEDOUT), а curl без --max-time подвисал на ещё-не-отвечающем порту и съедал
60-попыточный бюджет — integration падал на 'Chain API did not become ready'
при здоровой ноде. Узел не крашился (лог сплошь info), нужен лишь запас времени.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
ActionEvent отдавал только подмножество трассировки. Потребители (контроллер ЦК:
ledger2 связывает операцию с родительским apply по transaction_id + action_ordinal/
creator_action_ordinal; blockchain-explorer показывает receipt/ram-deltas/console)
требуют полный паритет с прежним транспортом. Данные уже декодируются wharfkit'ом —
ship-reader их просто не извлекал.
ship-reader: ShipTrace += creatorActionOrdinal/contextFree/elapsed/console/
accountRamDeltas; ActionReceipt += authSequence; извлечение в ShipProtocol из
action_trace (auth_sequence поддержан и как объект, и как кортеж). parser2:
BlockProcessor копирует поля в ActionEvent; типы и тесты обновлены.
ship-reader 0.1.0→0.2.0, parser2 1.0.3→1.1.0. Тесты: ship-reader 51, parser2 205 — зелёные.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
При emplace+erase строки в одном блоке chainbase::undo_index::on_remove
уничтожает узел без записи в _removed_values — это by-design оптимизация
для отката блока, но SHiP физически не видит такую транзиентную пару и
парсер её не индексирует. Описаны симптомы, когда возникает на практике,
workaround на стороне приложения (sleep ≥ block_time между транзакциями
или modify вместо erase) и план системного фикса в нашем форке coopos.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
coopops