Потрібно на поточній версії бота виправити баг.

Бюджет: 15000 UAH Термін: 3 дні

Добрий вечір, Сергію!

Готовий підключитися до поточного бота на aiogram 3 і виправити саме роботу очищувача «нор», не торкаючись діючої логіки чатів.

Спочатку локалізую причину збою: перевірю планувальник, часовий пояс, умови очищення через 7 днів, статуси в MySQL, чергу і TTL в Redis, повторні запуски, можливі гонки і обробку помилок.

Після діагностики:

— відтворю проблему на тестовій копії;
— внесу ізольоване виправлення;
— перевірю сценарії активного чату, здійсненої угоди, закритого чату і відсутності повідомлень більше 7 днів;
— налаштуваю зрозумілі логи очищувача;
— зроблю резервну копію перед розгортанням;
— перевірю роботу виправлення на сервері.

Переписувати робочу систему без необхідності не буду. Мета — усунути конкретний баг і не потягнути за собою інші частини проєкту.

Для старту потрібні репозиторій, доступ до логів і інформація, як зараз запускається очищувач: cron, окремий async-процес чи інший планувальник.

Термін — до 3 робочих днів.
Вартість — 15 000 грн.
Робота через Сейф. Розгорнути

Бюджет: 700 UAH Термін: 3 дні

Доброго вечора! Готовий узятись за цей баг. aiogram v3 + aiohttp + MySQL/Redis це наш щоденний стек, і розбиратись у чужому коді доводиться постійно.

По суті: чистильщик нір відпрацьовує не за графіком. У таких випадках причина зазвичай одна з трьох. Планувальник живе всередині воркера і перезапускається разом з ним; TTL останньої активності перезаписується не тим ключем у Redis; або час останнього повідомлення лежить у MySQL в іншій таймзоні, ніж та, за якою рахуються 7 днів. Спершу зніму лог одного повного циклу чистильщика і зіставлю його з реальними записами по кількох норах, тоді видно, де саме розходиться.

Працюю точково: правлю лише логіку планувальника і повернення нори в чергу, механіку чатів та решту не чіпаю. Перед виливом на прод показую diff і проганяю на копії бази, щоб фікс не потягнув за собою інших проблем.

Ціна 700 грн, термін 2-3 дні від моменту доступу до сервера й репозиторію. Беру за стартовою ціною, бо набираю перші відгуки на Freelancehunt.

Питання по ділу: чистильщик запущений як окремий asyncio-таск усередині бота, як APScheduler чи як системний cron? І де зберігається час останньої активності в норі, у MySQL чи в Redis з TTL? Від цього залежить, чи це правка на годину, чи планувальник треба виносити в окремий процес.

Є живі боти в роботі, можу показати в чаті.

Петро Панков, BotCraft Group Розгорнути

Бюджет: 12000 UAH Термін: 3 дні

По сроку - орієнтир 3 робочі дні на діагностику, правку чистильника нір, перевірку сценаріїв і акуратний випуск на сервері. По бюджету - 12000 грн, якщо проблема дійсно в розкладі, черзі або умовах очищення, а не в більш глибокій поломці моделі чатів.

Дивіться, тут нюанс - я б не чіпав роботу чатів ширше потрібного. Логіка така - перевіряю запуск чистильника, стан черги в MySQL або Redis, умови 7 днів без повідомлень, статуси угоди, потім роблю мінімальну правку і проганяю сценарії з активною угодою, закритим чатом, порожнім чатом і поверненням нори в чергу.

Від вас потрібні доступи до сервера, репозиторію або папки проекту, налаштування середовища через безпечний механізм біржі і приклад 1-2 нір, де чистка спрацювала неправильно. Код і серверні команди не виносимо за межі задачі.

Уточню 2 моменти, щоб не промахнутися з оцінкою
> чистильник зараз запускається через cron, окремий asyncio процес, aiohttp задачу або всередині основного бота
> черга нір зберігається в MySQL, Redis або в змішаній схемі

Схожі наші роботи
> https://business.ingello.com/platforma - платформа з ролями, бізнес-логікою і управлінням процесами
> https://business.ingello.com/forma-bpm - автоматизація черг, статусів і внутрішніх процесів
> https://systems-fl.ingello.com - основний профіль Ingello Systems для FLH

Якщо після діагностики виявиться, що проблема не в одному багу, а в архітектурі очищення і черг, окремо запропоную короткий етап проектування. Краще сім разів відміряти, ніж потім ремонтувати кожну нову нору вручну =) Розгорнути

Бюджет: 700 UAH Термін: 2 дні

Сергію, добрий день. Тут важливо виправити саме умови чистильника, не зачепивши анонімність та паралельні чати. Почну з відтворюваного сценарію збою і карти переходів: закритий чат, відсутня угода, 7 днів без активності, видалення учасників та повернення нори в чергу. Працюю з Python asyncio, aiogram 3, MySQL і Redis, правки зроблю точково та перевірю на граничних станах.

Бюджет: 4000 UAH Термін: 7 днів

Вітаю, я робив схожий Telegram-сервіс на aiogram v3 для взаємодії замовників і виконавців: профілі з ролями (RBAC), парні чати між сторонами, чергу діалогів, автоматичне очищення неактивних чатів за таймером на Redis. Розбір чужого коду прямо на сервері з aiohttp-вебхуками і MySQL теж був частиною тієї роботи.

Якщо чистильщик зараз чистить не за графіком, найчастіше причина в тому, що таймери живуть у пам'яті процесу і злітають при рестарті, тому варто перенести відлік 7 днів на TTL у Redis або окремий планувальник, це прибирає плаваючі спрацювання.

Підкажіть, чистильщик крутиться як окрема asyncio-задача чи через зовнішній планувальник, і скільки приблизно нір зараз у черзі? І де фіксується остання активність у чаті, в MySQL чи Redis?

Пропоную зв'язатись, заразом накидаю схему логіки чистильщика під ваші парні нори, щоб фікс не потягнув інших проблем.

Бюджет: 1200 UAH Термін: 2 дні

Працюю з aiogram v3 + asyncio/aiohttp, MySQL і Redis - розберусь у чужому коді без переписування. По опису схоже, що чистильник Нор не тримає графік через задачу, прив'язану до життєвого циклу вебхука і що не переживає рестарт, або через TTL ключів у Redis, які перетираються при повторному записі. Подивлюсь планувальник і логи прямо на сервері, відтворю кейс, покажу причину до правки, потім виправлю і залишу тест на розклад чистки. Перед будь-якими змінами роблю бекап коду та бази. Скажіть, будь ласка - бот на вебхуках через aiohttp і що зараз відповідає за розклад - APScheduler чи власний цикл?

Бюджет: 1000 UAH Термін: 1 день

Вітаю. Мене звати Володимир, я Python та Node.js розробник, а також засновник інженерного агентства Vaysed. Я детально ознайомився з вашим завданням щодо виправлення бага в існуючому Telegram-боті на aiogram 3. Розумію, що потрібно полагодити алгоритм чистильника проксі-чатів, який має за розкладом коректно звільняти неактивні парні чати без шкоди для решти функціоналу бота.

Проблема з порушенням графіка очищення найчастіше криється в некоректному використанні asyncio, блокуванні event loop іншими процесами бота або відсутності надійного планувальника, який би зберігав стан у Redis. Оскільки ви вже використовуєте Redis, я пропоную провести швидкий аудит поточного скрипта чистильника безпосередньо на вашому сервері. Я знайду причину збою таймерів і оптимізую цей модуль, перевіривши логіку звірки таймстампів останньої активності та статусу угод з MySQL. Це гарантує, що неактивні понад 7 днів чати будуть стабільно очищуватися і повертатися в чергу, а поточні діалоги не постраждають. Усі правки будуть внесені точково та безпечно.

Я маю великий досвід розробки складних ботів на aiogram 3, роботи з вебхуками та управління асинхронними чергами. Наприклад, під час розробки системи Lumos я реалізував безперебійні процеси, що працюють за строгими графіками 24/7 без жодних збоїв. Також у проєкті PAYBACK CARTEL я будував надійну архітектуру маршрутизації та керування сесіями.

Ознайомитися з моїм портфоліо можна за цим посиланням: Freelancehunt

Пропоную перейти в особисті повідомлення для обговорення доступу до сервера та перегляду логів роботи вашого чистильника.

Бюджет: 1500 UAH Термін: 1 день

Добрий вечір. Займаюсь розробкою та налаштуванням Telegram ботів. Можу допомогти з вирішенням Вашої проблема, швидко проведу діагностику та виправлю проблему. Готовий обговорити деталі та приступити до роботи, пишіть.

Бюджет: 1111 UAH Термін: 11 днів

Добрий день, є великий досвід в цьому, але не бачивши коду важко щось сказати. Дуже бажано подивитися код, потім можна буде щось сказати конкретніше.

Бюджет: 2000 UAH Термін: 2 дні

Доброго дня. З усім перерахованим працював. Можу взятися. По ціні вирішимо, дивлячись скільки там за обсягом потрібно буде виправляти. Взагалі, якщо що, то давайте обговоримо детально, покажете в якому місці не працює, я по коду гляну вже.

Бюджет: 1500 UAH Термін: 2 дні

Вітаю.Головний виклик цього завдання — стабілізувати роботу фонового "чистильника" анонімних чатів ("Нір"), не зламавши при цьому існуючий роутинг повідомлень в aiogram v3. Те, що чистильник порушує графік, зазвичай свідчить про блокування asyncio event loop, некоректну роботу поточного планувальника завдань або зависання транзакцій при перевірці статусу угод і 7-денної неактивності.
Я локалізую баг безпосередньо на сервері: оптимізую MySQL-запити для точного трекінгу часу останнього повідомлення та налаштую надійний механізм скидання порожніх чатів назад у чергу через існуючий Redis. Усе це зроблю точково, зберігши поточну логіку ізоляції (парні чати) замовників і виконавців без змін.
Маю глибокий досвід роботи зі складними Telegram-архітектурами на aiogram v3.

Бюджет: 1250 UAH Термін: 2 дні

Привіт! Зрозумів проблему з чатами (норами): вони не очищуються за графіком і не повертаються в чергу. У мене є досвід розробки Telegram-ботів на асинхронному Python з роботою через вебхуки, MySQL та Redis. Точно працював з логікою автоочистки чатів за таймерами та повторної постановки в чергу.

В якому форматі зберігаєте мітку часу останнього повідомлення в чаті?

Бюджет: 700 UAH Термін: 2 дні

Сергію, ключовий ризик тут — що «чистильник» нір чіпляє стан угод у Redis і зв'язки юзерів у MySQL. Якщо лаг просто підправити, можна непомітно зламати чергу: нору поверне в оборот, а там ще активна угода.

Підхід до фіксу:
— спершу трасую поточний алгоритм чистильника: що саме тригерить очищення (cron, event loop) і які умови перевіряє перед видаленням
— відновлю логіку «7 днів без повідомлень OR чат закрито AND немає активної угоди» — щоб нора поверталась в чергу тільки за коректної умови
— перевірю, як Redis-стан парних нір синхронізується з MySQL при скиданні — рассинхрон там найчастіше й ламає графік

Нюанс, який важливо перевірити: дві паралельні нори (виконавець / замовник) мають чиститись симетрично. Якщо одну очистить раніше — другий юзер залишиться в чаті без співрозмовника. Це, швидше за все, і є джерело бага.

aiogram v3, asyncio та розбір чужого коду — моя щоденна робота. Вебхуки, Redis-стан і MySQL-зв'язки — стек під цю задачу.

Працюю через Сейф: спершу локально розберу алгоритм чистильника й покажу, де саме ламається логіка — далі фікс на сервері. Для старту знадобиться доступ до репозиторію та SSH.

Питання по суті: чистильник зараз запускається через APScheduler/Cron чи це asyncio-таск усередині бота? Розгорнути

Бюджет: 1500 UAH Термін: 2 дні

Впринципі задача зрозуміла треба полагодити фоновий таск (чистильник) для чатів, бо він збивається з графіка і не відраховує нормальні 7 днів.

з таким стеком працюва (aiogram v3, asyncio, redis, mysql), з юзерботами і фоновими процесами працював.

готовий ьистро виправити вашу проблему

Бюджет: 1500 UAH Термін: 1 день

Доброго дня, Сергію.

Судячи з опису, проблема полягає або в самому асинхронному завданні планувальника (коли падають фонові завдання через неперехоплені помилки), або в некоректному вибірці дат останньої активності з MySQL — точно сказати складно, треба дивитися. Можу зайти на сервер і вивчити код, обережно, щоб не зачепити нічого іншого.

Підкажіть, чи чистильник крутиться всередині самого процесу бота через asyncio/APScheduler, чи винесений окремим скриптом під systemd/cron?

Я активно пишу на Python (включаючи aiogram v3, MySQL, Redis та async) з кількома роками досвіду за плечима, без проблем розбираю чужий код і маю досвід у ботоділлі — можете подивитися в відгуках.

Напишіть мені в особисті повідомлення, обговоримо деталі і я одразу візьмуся за задачу.

Бюджет: 1500 UAH Термін: 2 дні

Здравствуйте, Сергей. У сервісів на aiogram v3 з чергою «нор» така нерегулярна чистка найчастіше пояснюється тим, що чистильник тримає відлік 7 днів у пам'яті процесу, через asyncio-task або sleep-цикл, і будь-який перезапуск бота або деплой скидає ці таймери без сліду в логах, частина чатів просто випадає з графіка. Перевірю, крутиться чи у вас чистильник саме так або через зовнішній планувальник, і звідки береться позначка останньої активності, з MySQL чи Redis, від цього залежить, де саме рветься логіка.

Якщо причина в таймерах, перенесу перевірку на періодичний ідемпотентний прохід по last_activity в MySQL зі звіркою в Redis, який переживає перезапуск і не чіпає парні чати та чергу заявок, змінювати буду тільки самого чистильника. Перед викладкою на прод перевірю фікс на парі тестових нор з штучно состареною активністю, щоб побачити, що бот звільняє учасників і повертає чат у чергу так, як задумано.

По грошах і термінах, 1500 грн, 2 дні з моменту доступу до сервера і логів. Скажіть, є SSH і тестове середовище або копія бази, щоб перевіряти фікс не на бойових чатах?

Бюджет: 3800 UAH Термін: 5 днів

Поняв суть: чистильщик нор повинен перевіряти за розкладом угоду та активність за 7 днів, а зараз він ламається, черга не звільняється вчасно.

Підключусь до сервера, розберу код чистильника та планувальника, знайду, де збивається умова по MySQL та Redis, поправлю точково, не чіпаючи логіку чатів та нор.

Готовий за 5 днів. Чистильник зараз окремий воркер чи через cron?

Бюджет: 18000 UAH Термін: 4 дні

у нас вже є практично готові рішення по телеграм-ботах з чергами, ролями, фоновими завданнями та ІІ-автоматизацією, тому можемо швидко зайти в поточний код і акуратно виправити проблему

по термінах - орієнтир 2-4 дні після доступу до сервера та репозиторію
по бюджету - 18000 грн за діагностику, виправлення та перевірку на робочому сценарії

дивіться, тут нюанс - в таких завданнях важливо не просто поправити чистильник, а перевірити всю ланцюг
> створення нір
> постановка в чергу
> перевірка угоди та активності за 7 днів
> видалення учасників
> повернення чату в чергу
> відсутність побічних змін у поточній логіці чатів

роботу чатів і основну механіку не змінюємо
робимо точковий розбір поточного алгоритму, логування причин збою, виправлення розкладу або умов очищення, потім тестуємо на сервері або на копії бази

для точної оцінки потрібно уточнити 2 моменти
> чистильник зараз зроблений через окремий asyncio-процес, cron, celery-подібну чергу чи всередині самого бота
> чи є тестовий сервер або можна працювати тільки на бойовому з резервною копією бази

схожі за змістом кейси
> https://business.ingello.com/vorfahr - автоматизація сервісу з ІІ та складною логікою процесів
> https://business.ingello.com/fractal - агентні та автоматизаційні процеси, де важливі черги та надійне виконання завдань
> https://systems-fl.ingello.com - профіль Ingello Systems для проектів автоматизації та розробки

на зв'язку, можемо почати з короткої діагностики поточного коду та логів =) Розгорнути

Бюджет: 2000 UAH Термін: 1 день

Вітаю.

Можу розібратися з поточною реалізацією «нор» і виправити роботу чистильника без зміни існуючої логіки чатів.

Працюю з Python, асинхронним кодом, aiogram 3, aiohttp, MySQL та Redis. Спочатку перевірю повний цикл роботи чатів: створення парних нір, призначення замовника й виконавця, фіксацію активності, статус угоди, очищення неактивних чатів і повернення вільних нір у чергу.

Окремо перевірю:

* чому чистильник запускається не за графіком;
* коректність визначення семи днів неактивності;
* чи враховується активна або завершена угода;
* синхронізацію двох паралельних чатів;
* роботу Redis-черги;
* повторне додавання однієї нори в чергу;
* паралельний запуск кількох екземплярів чистильника;
* часовий пояс сервера;
* обробку помилок Telegram API;
* логування очищення та причин пропуску чатів.

Внесу мінімальні зміни саме в проблемний модуль, щоб не зачепити іншу функціональність бота. Перед виправленням зафіксую поточну логіку, зроблю резервну копію змін і перевірю роботу на тестових норах.

Після завершення надам короткий звіт: у чому була причина, які файли змінено, як тепер працює алгоритм і як перевірити чистильник на сервері. Розгорнути

Бюджет: 3500 UAH Термін: 3 дні

Добрий день, Сергій!

Мене звати Роман, і я уважно ознайомився з описом вашого проєкту щодо налагодження Telegram-бота на aiogram v3 з проблемою у функціоналі чатів, а саме з чистильником “Нір”. Я маю значний досвід роботи з aiogram v3, асинхронним програмуванням (asyncio) та aiohttp, а також з базами даних MySQL та Redis, що є ключовими технологіями вашого бота. Розумію, що коректна робота чистильника, який повертає невикористані “Нори” у чергу, критично важлива для ефективності вашої системи взаємодії замовників та виконавців. Мій підхід зосереджений на ретельному аналізі існуючого коду, що дозволить мені локалізувати та усунути причину некоректної роботи чистильника, не зачіпаючи інших функціональних частин бота, як ви зазначали.

Моїм планом дій є наступне: по-перше, я проведу детальне вивчення логів та поточної реалізації чистильника на вашому сервері, щоб точно ідентифікувати баг, який призводить до його некоректної роботи та несвоєчасного очищення чатів. По-друге, я розроблю та протестую виправлення, яке забезпечить роботу чистильника згідно з алгоритмом 7-денного періоду та встановленням чатів назад у чергу. По-третє, я проведу комплексне тестування, щоб переконатися, що виправлення не спричинило нових помилок і що всі інші механізми бота, включаючи створення "Нір" та паралельні чати, функціонують бездоганно. Я відповідальний, пунктуальний і завжди приділяю увагу деталям, що дозволить мені забезпечити стабільну та надійну роботу вашого бота.

Вартість робіт становить 3500 грн, термін – 3 робочі дні. Я готовий надати посилання на аналогічні виконані проєкти в приватні повідомлення, щоб ви могли оцінити мій рівень експертизи. Як приємний бонус, я надаю безкоштовну 7-денну підтримку після здачі проєкту, щоб ви були впевнені у стабільній роботі виправленого функціоналу. Чи є у вас вже якісь припущення щодо можливої причини багу в чистильнику, які могли б прискорити діагностику?

Бюджет: 1500 UAH Термін: 1 день

Доброго дня, Сергію!

Готовий подивитись прямо на сервері. За описом схоже на одну з трьох типових причин: задача-чистильник висить на asyncio.sleep у циклі і тихо вмирає без запису в лог при рестарті/мережевій затримці; або транзакція чистки комітиться не в тому з’єднанні з пулу MySQL, тому інші частини бота бачать застарілі дані; або Redis тримає TTL-мітку розкладу, яка протухає не туди. Знаю, де шукати в кожному випадку.

Стек — aiogram v3, asyncio, MySQL + Redis разом — це мій основний профіль, працював з такою комбінацією в бойовому проєкті з живим моніторингом через Telegram.

Питання: чи є SSH-доступ до сервера і логи за останні збої чистильника? Без бюджету орієнтуюсь на 1500–2500 грн, 1–2 дні, залежно від читабельності коду.

github.com/kamedashe

Богдан Розгорнути

Бюджет: 4000 UAH Термін: 2 дні

Схоже, що чистильник чатів працює не за графіком — проблема в асинхронному планувальнику (ймовірно, asyncio loop або Redis черга). Швидко діагностую, правлю прямо на сервері, з бекапом і rollback. План: 1) Аналіз коду cleaner та його тригерів; 2) Виправлення логіки планування (якщо потрібно — заміна на apscheduler або перевірка корутин); 3) Тестування в робочому середовищі. Маю досвід зі складними асинхронними системами (наприклад, автоматизований Twitter-менеджер на Selenium + Python) [1]. Дайте доступ до сервера та. уточніть: який графік чищення має бути? Чи є вже тестове середовище? Приклад роботи: https://freelancehunt.com/showcase/work/programmnoe-obespechenie-dlya-twitter-avtomatizirovannoe-upravlenie/1874481.html

Ціна: 4000 UAH
Термін: 2 днів

Бюджет: 1500 UAH Термін: 1 день

Привіт, маю досвід у ботобудуванні більше 5 років, пишіть, допоможу! Швидко вирішу вашу проблему)

Бюджет: 3400 UAH Термін: 4 дні

Задача зрозуміла: чистильник нір працює з багами, не за графіком, не звільняє чати через 7 днів неактивності і не повертає їх у чергу.

Я підключусь до сервера, розберу поточну логіку планувальника (cron/asyncio task) і умови перевірки останньої активності в MySQL, знайду, де ламається розклад і чому не спрацьовує видалення учасників з чату. Правки зроблю точково, без змін решти логіки чатів, парних нір і Redis-черги.

Термін: близько 4 днів. Уточніть доступи до сервера і репозиторію після старту.

Бюджет: 1100 UAH Термін: 1 день

Вітаю.

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

Бюджет: 1000 UAH Термін: 1 день

Вітаю.
Ретельно проаналізую поточну реалізацію механізму "чистильника" в контексті архітектури aiogram v3, асинхронних процесів та взаємодії з MySQL і Redis. Особливу увагу приділю виявленню некоректних умов, race conditions або помилок у роботі з даними, що призводять до порушення логіки очищення чатів та їх повернення у чергу. Впроваджу виправлення, забезпечуючи точне дотримання графіка очищення та стабільність існуючих функцій чатів, використовуючи паттерни ідемпотентних операцій. Маю значний досвід у розробці та оптимізації фонових процесів для Telegram-ботів, а також готові шаблони для тестування та деплою подібних фіксів. Всі деталі реалізації, кінцевий бюджет та терміни пропоную обговорити в особистих повідомленнях.

Бюджет: 700 UAH Термін: 1 день

Вітаю! Готовий оперативно підключитися, розібратися у вашому коді та пофіксити баг у Telegram-боті прямо зараз.

Я розробник, спеціалізуюся на асинхронному Python та автоматизації. Маю впевнений практичний досвід роботи саме з aiogram v3 (включаючи роботу з FSM, мідлварями та кастомними фільтрами), а також чудово розумію логіку асинхронних запитів через aiohttp, роботу з вебхуками, базами MySQL та кешуванням у Redis.

Чудово вмію читати та рефакторити чужий код. Зроблю все швидко та акуратно, не зламавши поточну архітектуру сервісу. Ціна невелика, оскільки тільки починаю на цьому профілі й працюю на перший відгук і рейтинг.

Готовий перейти в особистий чат прямо зараз

Бюджет: 1000 UAH Термін: 1 день

Доброго дня, готовий виконати ваше завдання швидко та якісно. маю великий досвід у створенні різноманітних ботів. Напишіть у особисті повідомлення обговоримо деталі. Залюбки допоможу)