The post has been translated automatically. Original language: Russian
On September 10, 2026, version 1.17.1 of the open platform Dify was released, an application builder based on large language models with knowledge bases, workflows, and agents. Formally, this is a patch release, but it contains a layer of errors that caused the contents of documents to change silently during import, access to service keys was restricted, and there was a strict requirement for the update procedure.
API keys can now be linked to a single knowledge base.
Previously, the knowledge base service key was valid for the entire workspace: it read and wrote any database in the tenant, so access to one database could not be granted. Now, when creating a key, there is a choice of scope: the entire workspace or a specific knowledge base. The linked key returns the 403 code for any foreign database, as well as for endpoints without a database ID. Previously issued keys remain unbound and retain the same behavior.
Importing documents changed the data without errors
The most frustrating part of the release is the text extraction fixes. These defects did not give error messages, the index simply contained distorted text.:
- CSV cells were run through automatic type detection: codes with leading zeros turned into floating—point numbers (the value "00123" became "123.0"), empty cells into the string "nan", and the values "NA" and "NULL" into gaps. Now everything reads like text.
- Tables from Notion lost and gained columns: each formatting fragment inside a cell was displayed as a separate column, and an empty cell was skipped and moved the row to the left.
- Any PDF downloaded from the link crashed with a bare AssertionError; the embedded web scraper also fell under this when the site returned the "application/pdf" content type. In addition, the scraper itself returned not the page text, but the raw Python structures.
Two operational problems were also closed: a document with many incorrect links to images went into a cycle of repeated download attempts and kept the indexing worker for so long that the entire queue got up behind it; and deleting documents cleared the rows in the database, but left the files in storage.
Updates and migrations
For independent installations with built-in Weaviate, it is necessary to upgrade stepwise: the server is moving from version 1.27.0 to 1.39.2, these are 12 minor versions, and jumping over them is not supported — a simple image update with a restart can irreversibly ruin vector search. External Weaviate, other repositories and new installations are not affected.
Migration of outdated model types, which in versions 1.16.1 and 1.17.0 had to be run with a separate command, was integrated into the usual "flask db upgrade". The Human Input node was corrected in the workflows: the timeout branch was triggered incorrectly because the editor wrote the label "__timeout", and the backend compared it with "__timeout__".
What does this mean in practice?
The main conclusion is that the index could contain distorted text for a long time, and the log won't tell you about it. Corrections are applied only to new imports — already indexed documents are not retroactively repaired, they will have to be re-imported. Start with the tables: where there are articles, IINS and contract numbers, the leading zeros turned into numbers, and the search for the exact code stopped finding the document.
Before updating, check which vector storage you actually use. If this is an embedded Weaviate, schedule a window to step through the versions and take a backup copy of the volume: the price of an error here is a lost index.
MySQL users are interested in correcting the "One or more files not found" error when creating and updating documents: it occurred due to the REPEATABLE READ isolation level, when a snapshot of the read was captured before the file download was committed in another session. There was no defect on PostgreSQL.
Finally, the keys issued to external integrations should be recreated with reference to a specific database — their scope does not automatically narrow.
The draft text was prepared with the participation of AI, the facts were checked against the original source — the official notes on the release of Dify version 1.17.1 on GitHub.
10 сентября 2026 года вышла версия 1.17.1 открытой платформы Dify — конструктора приложений на больших языковых моделях с базами знаний, рабочими процессами и агентами. Формально это патч-релиз, но в нём закрыт пласт ошибок, из-за которых содержимое документов менялось при импорте молча, появилось разграничение доступа для сервисных ключей и возникло жёсткое требование к порядку обновления.
Ключи API теперь можно привязать к одной базе знаний
Раньше сервисный ключ базы знаний действовал на всё рабочее пространство: он читал и писал любую базу в тенанте, так что доступ к одной базе выдать было нельзя. Теперь при создании ключа есть выбор области действия: всё рабочее пространство или конкретная база знаний. Привязанный ключ возвращает код 403 для любой чужой базы, а также для эндпоинтов без идентификатора базы. Ранее выданные ключи остаются непривязанными и сохраняют прежнее поведение.
Импорт документов менял данные без ошибок
Самая неприятная часть релиза — исправления в извлечении текста. Сообщений об ошибке эти дефекты не давали, в индекс просто попадал искажённый текст:
- Ячейки CSV прогонялись через автоматическое определение типов: коды с ведущими нулями превращались в числа с плавающей точкой (значение «00123» становилось «123.0»), пустые ячейки — в строку «nan», а значения «NA» и «NULL» — в пропуски. Теперь всё читается как текст.
- Таблицы из Notion теряли и приобретали столбцы: каждый фрагмент форматирования внутри ячейки выводился как отдельный столбец, а пустая ячейка пропускалась и сдвигала строку влево.
- Любой PDF, загружаемый по ссылке, падал с голым AssertionError; под это попадал и встроенный веб-скрапер, когда сайт отдавал тип содержимого «application/pdf». Сам скрапер вдобавок возвращал не текст страницы, а сырые структуры Python.
Закрыли и две операционные проблемы: документ со множеством некорректных ссылок на изображения уходил в цикл повторных попыток загрузки и держал воркер индексации так долго, что за ним вставала вся очередь; а удаление документов чистило строки в базе, но оставляло файлы в хранилище.
Обновление и миграции
Для самостоятельных установок со встроенным Weaviate обновляться обязательно ступенчато: сервер переезжает с версии 1.27.0 на 1.39.2, это 12 минорных версий, и перепрыгивать их не поддерживается — простое обновление образа с перезапуском способно необратимо испортить векторный поиск. Внешний Weaviate, другие хранилища и новые установки это не затрагивает.
Миграцию устаревших типов моделей, которую в версиях 1.16.1 и 1.17.0 надо было запускать отдельной командой руками, встроили в обычный «flask db upgrade». В рабочих процессах поправили узел Human Input: ветка по таймауту срабатывала не та, потому что редактор писал метку «__timeout», а бэкенд сравнивал её с «__timeout__».
Что это значит на практике
Главный вывод: индекс мог долго содержать искажённый текст, и лог об этом не скажет. Исправления применяются только к новому импорту — уже проиндексированные документы задним числом не чинятся, их придётся переимпортировать. Начните с таблиц: там, где есть артикулы, ИИН и номера договоров, ведущие нули превращались в числа, и поиск по точному коду переставал находить документ.
Перед обновлением проверьте, какое векторное хранилище у вас реально используется. Если это встроенный Weaviate, запланируйте окно на ступенчатый проход по версиям и снимите резервную копию тома: цена ошибки здесь — потерянный индекс.
Пользователям MySQL интересно исправление ошибки «One or more files not found» при создании и обновлении документов: она возникала из-за уровня изоляции REPEATABLE READ, когда снимок чтения фиксировался раньше, чем загрузка файла коммитилась в другой сессии. На PostgreSQL дефекта не было.
Наконец, ключи, выданные внешним интеграциям, стоит пересоздать с привязкой к конкретной базе — автоматически их область действия не сужается.
Черновик текста подготовлен с участием ИИ, факты сверены с первоисточником — официальные заметки о выпуске Dify версии 1.17.1 на GitHub.