Баги n8n v4.4 и загрузка файлов в VK API: лечим ERR_UPLOAD_BAD_SIGNATURE и потерю метаданных

Автоматизация выгрузки отчетов в социальные сети часто превращается в каскад ошибок из-за специфики API и скрытых багов инструментов. В этой статье разберем, как загрузить Excel-отчет на сервера ВКонтакте (метод docs.save) через n8n v2.11.3, победить «тихое» затирание бинарных данных и исправить некорректную работу узла HTTP Request v4.4.

Проблема: Двухэтапная загрузка и хрупкая подпись

Загрузка файлов в VK — это всегда два шага: сначала получение upload_url, затем POST-запрос с файлом. Главная сложность в том, что upload_url содержит одноразовую цифровую подпись (sig), которая инвалидируется при малейшем изменении строки запроса.

Ошибка 1: ERR_UPLOAD_BAD_SIGNATURE

Если в узле загрузки оставить включенной авторизацию (VK API Credentials), n8n автоматически приклеит access_token в конец URL.

• Физика процесса: Любое добавление параметров после получения ссылки ломает подпись. VK воспринимает это как попытку подделки запроса.

• Решение: В узле POST-запроса жестко ставим Authentication: None. Ссылка уже самодостаточна.

Разбор «граблей» n8n v4.4: Куда исчезает файл?

Даже при правильной ссылке часто возникает ошибка 400 no_file. Это связано с багами реализации узла HTTP Request версии 4.4.

Потеря метаданных (filename)

VK отказывается принимать данные, если в заголовке Content-Disposition отсутствует имя файла (например, filename="report.xlsx"). Узел v4.4 часто теряет эти метаданные при передаче бинарника между узлами.

Затирание контекста

Узел, запрашивающий upload_url, затирает входящий бинарный поток своим JSON-ответом. В итоге до узла отправки файл просто не долетает.

Инженерное решение: Паттерн «Absolute Context Hooking»

Чтобы обойти баги версии 4.4, необходимо использовать узел Code для принудительного сбора данных из разных веток истории выполнения и ручного формирования объекта файла.

Шаг 1: Подготовка «таблетки» (Узел Code)

В новых версиях n8n (2.x+) метод getBinaryData() признан устаревшим. Используем прямой доступ к объекту $binary и абсолютные пути к узлам.

JavaScript

// Mode: Run Once for Each Item// 1. Берем ссылку из узла получения URLconst uploadUrl = $('ИМЯ_УЗЛА_GET_URL').first().json.response.upload_url;// 2. Достаем бинарник напрямую из узла генерации отчетаconst excelNode = $('ИМЯ_УЗЛА_ГЕНЕРАЦИИ').first();const fileData = excelNode.binary.file;// 3. Формируем объект с жестко заданными метаданнымиreturn {  json: {    upload_url: uploadUrl  },  binary: {    file: {      ...fileData,      fileName: 'report.xlsx',      mimeType: 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet'    }  }};

Шаг 2: Настройка узла HTTP Request (POST)

Для корректной упаковки данных в multipart/form-data используйте следующие параметры:

• URL: {{ $json.upload_url }}.

• Authentication: None.

• Body Content Type: Form-Data.

• Параметр: Тип Binary, Name: file, Data Property Name: file.

Главные выводы

1. Токены ломают загрузку: Никогда не используйте Credentials в узлах, работающих с одноразовыми upload_url.

2. Метаданные критичны: Если API пишет no_file, на 90% проблема в отсутствии fileName в заголовках.

3. Прямые ссылки: В сложных воркфлоу всегда обращайтесь к бинарным данным через $('ИМЯ_УЗЛА').first().binary, чтобы избежать их потери при затирании контекста другими HTTP-узлами.

P.S. Я профессионально занимаюсь автоматизацией сложных инфраструктурных задач на n8n. Если вы столкнулись с багами платформы, которые кажутся непреодолимыми, или вам нужна помощь в проектировании отказоустойчивых интеграций — пишите мне в Telegram. Буду рад разобрать ваш кейс.