SB
ничего не знал о кафке до этого момента. вбил в гугл "kafka partitioning order" и в первом же линке прочел страшное.
Ты мог бы быть нашим новым главным по технологическим трансформациям.
Этот сдк — кусок поноса.
У чувака падает кусок кода на выполнении простого запроса, и нихуя не понятно почему: жалуется Newtonsoft (прибитый гвоздями поверх эпоксидки к сдк), что какого-то поля не хватает. Другой разработчик скопировал код к себе — и все заработало. Я проверил у себя — не работает. Спустя час совместного дебага удалось обнаружить, что проблема исключительно в десериализации — данные приходят корректные. Там, куда чувак себе скопировал код, в
DocumentClient явно прописаны настройки сериализации, а у нас их явно задать нельзя (пушто attribute binding for Azure Function), но мы все правильные настройки запихали в дефолт. Т.е. если тупо вызвать JsonConvert.DeserializeObject<_>, то все работает как надо.Чудом обнаружили, что если прописать
UseDefaultJsonSerialization = true в байндинг атрибуте, то все начинает работать (хуй знает, какие настройки он берет, если этот сеттинг не задать, ведь блять по умолчанию же используется обычно то, что сука по умолчанию, да?).Теперь непонятно следующее: какого хуя все остальные наши функции работают нормально без этой настройки с тем же атрибутом и
DocumentClient? А дело вот в чем: в остальных функциях мы вызывали у него метод getById, и (де)сериализация в нем работает по одним законам. А тут мы вызвали метод CreateDocumentQuery и после него ExecuteNextAsync. И там блять ВНЕЗАПНО оказалось, что сериализация работает совсем с другими настройками. С какими? Да хуй его знает, мы даже с помощью райдера и его декомпилятора не смогли продраться сквозь это ебучее раковое ООП ради ООП с слоями ООП скрытыми за красивыми фасадами ООП.КАК ЖЕ СУКА ГОРИТ БЛЯТЬ