Суб-оркестровка Durable Functions никогда не возвращается к родительской оркестровке

У меня есть суб-оркестровка, которая включает в себя несколько действий. Одно из действий вызывается ~ 150 раз, и каждое действие помещается в список задач, затем ожидает Task.WhenAll (список). Каждая из этих задач возвращает изображение в кодировке base64, поэтому сообщения находятся на большей стороне.

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

У меня есть точка останова в родительской оркестровке на следующем шаге после получения результатов от суб-оркестрации, но она никогда не срабатывает. Результаты никогда не возвращаются к родителю.

Может ли это быть связано с размером сообщения, возвращаемым суборганизацией?

Если я встраиваю код вспомогательной оркестрации в родительскую оркестровку вместо того, чтобы вызывать его как вспомогательную оркестровку, он работает нормально.


azure-functions azure-durable-functions
person Dexterity    schedule 07.11.2018    source источник
comment
Можете ли вы опубликовать код, чтобы можно было получить более подробную картину.   -  person Sebastian Achatz    schedule 08.11.2018
comment
Похоже на ошибку. Это воспроизводится в Azure? Если да, можете ли вы поделиться родительским идентификатором оркестровки и регионом, в котором работает ваше приложение?   -  person Chris Gillum    schedule 08.11.2018
comment
Я удалил экземпляр для этого конкретного вопроса, но я настраиваю другой, чтобы попытаться воспроизвести именно этот. На другой виртуальной машине у меня есть нечто подобное, где родительский элемент находится в рабочем состоянии, а три суб-оркестровки просто находятся в рабочем состоянии, и поэтому вся оркестровка застряла на 30 минут. Родительский идентификатор исполнения - 25114a61c21c406a8a27cb4b6f8be8aa, дочерние элементы: 100e21285a8549bb91dbab571220c639, 85d9b7bfd3cf4420ba2aae66e42ce67d, 06a214ccbb884b44bf41c37e64, Канада, Восток8.   -  person Dexterity    schedule 09.11.2018
comment
Я воспроизвел это точно так же, как вопрос, на другом сервере Canada East. Ключ родительского раздела / идентификатор выполнения / идентификатор приложения: ad051bbe8514493194c138f40e11ddb2, 50863b66b1ca4df183d71c897970d182, ad051bbe8514493194c138f40e11ddb2.   -  person Dexterity    schedule 09.11.2018
comment
Случайно отправлено вот остальное: Ключ дочернего раздела / Идентификатор выполнения / Идентификатор аналитики приложения: 50863b66b1ca4df183d71c897970d182, 19887ac47871429ca73f0de0d6552f9a, 6cadae6e-92c5-4dc5-8b23-784bb401eb11 со статусом 4bb23-784bb401eb11. -acd4-2137792e2f46 (81,5 мб) Родитель только что имеет статус "Выполняется". В App Insights нет движения, но выделено ~ 2 ГБ памяти. Последняя трассировка аналитики приложения была выполнена дочерней оркестровкой   -  person Dexterity    schedule 09.11.2018
comment
Есть обновления здесь? Я оставил эти приложения в таком состоянии для проверки, но вскоре мне придется удалить их. Первый экземпляр все еще находится в том же состоянии (последнее действие 3 дня назад), второй продолжился с того места, где он остановился 12 часов спустя, но затем оказался в другом застопоренном состоянии и все еще сидит там (последнее действие 2 1/2 дней назад).   -  person Dexterity    schedule 12.11.2018
comment
У меня такая же проблема с вызовом небольшого количества действий из родительской оркестровки. Кажется, что родительский элемент отменяется после вызова CallSubOrchestratorAsync. Все дальнейшие действия не выполняются.   -  person jhoefnagels    schedule 03.07.2019

Ответы (1)


arrow_upward
0
arrow_downward

Похоже, это ошибка в структуре долговременных функций. Я столкнулся с той же проблемой с оркестратором Javascript, который заканчивался сразу после завершения суборганизации и без выполнения кода после суборганизации. Проблема, по-видимому, связана с ошибкой, из-за которой структура устойчивых функций не может получить выходные данные суборганизации из сохраненного состояния, если суборганизация не имеет определенного instanceId. Таким образом, указав instanceId, код будет выполняться нормально.

Мой код оркестратора, который давал сбой, выглядел так:

var reboot_result = yield context.df.callSubOrchestrator('reboot_orchestrator',reboot_input);
context.log('this is the next line after subOrch call which will not get called');

Контекст.log никогда не будет вызван. Поэтому я вручную указываю instanceId для callSubOrchestrator, и это устранило проблему :)

const child_id = context.df.instanceId + ":0"; //create instanceId
var reboot_result = yield context.df.callSubOrchestrator('reboot_orchestrator',reboot_input,child_id);
context.log('this is the next line after subOrch call and now it gets called properly');

Вот ссылка на отчет об ошибке Github: https://github.com/Azure/azure-functions-durable-js/issues/54

person Juan Pablo Olivo    schedule 16.08.2019