Сергей П

Так а в чем проблема-то? Вы как-то попробовали и у вас не получилось? PNG-картинку с прозрачностью не вариант поставить?

Это ваше собственное определение про обратное наследование?
Родительский класс ничего не знает о методах потомков.
Полиморфизм нужен для организации уровня абстракции.
У автомобиля есть абстрактный интерфейс: разгоняться, тормозить, поворачивать. Вы применяете соответствующие методы, а под капотом происходит полиморфизм в зависимости от того, на какой машине вы едете: на ДВС при ускорении отодвигается заслонка, обогащается сместь, поступает в форсунки, увеличиваются обороты; у электромобиля частотник увеличивает частоту, синусоиды, идущей на двигатели, он начинает крутиться быстрее... Потом кто-то придумал гибрид и там всё гораздо сложнее, но на уровне "предка" обо всём этом не нужно думать, благодаря полиморфизму мы имеем простые понятные методы, которые у потомков реализованы по-своему.

Например прописать в crontab через директиву `@reboot`. Только пути надо даже для бинарников абсолютные указать.

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

Общие правила работы с кодировками в питоне я уже много раз рассказывал на этом ресурсе.
На входе в программу мы всё переводим в юникод, а на выходе всё кодируем в байты.
Для ясности: юникод - это не кодировка, это абстрактный способ однозначной нумерации символов. Кодировка - это способ представить символ (а символ имеет свой однозначный код в таблице Юникода) в виде набора байт.
Итак, текст в юникоде - - это, образно говоря, последовтаельность номеров символов из таблицы юникода.
Текст в любой кодировке - это последовательность байтов.
Важно отметить, что так или инае номера юникода тоже внутри компа хранятся как байты, а питон с ними работает не как с массивом чисел, а как с объектом "строка", значит внутри он всё же хранит юникод в какой-то специальной кодировке, но тут есть важная деталь.

Есть кодировки, способные представить ВСЕ возможные символы Юникода, а есть кодировки, которые могут представить только некоторое подмножество этих символов. К первым относятся UTF-8, UTF-16, UTF-32 - они по-разному представляют номер символа таблицы Юникод в виде байтов, но способны представить любой символ.
Ко вторым, к примеру, однобайтовые кодировки cp1862, cp866, koi8 прочие. Такие кодировки - пережиток прошлого, когда в угоду простоте люди жертвовали универсальностью. Однако со временем, когда требоания к ПО и набору поддерживаемых символов изменилось, появилась необходимость как-то между этими кодировками переключаться, преобразовывать тексты, учитывать, что какойто текст без потери данных вовсе нельзя перевести из одной в другую кодировку, потому что каких то букв просто нет в целевой кодировке. Так простота накопилась техническим долгом и обернулась многократно возросшей сложностью учета всех этих нюансов.

В питоне внутри для хранения юникод-строк (а в 3 питоне это основной вид строк) используется не помню какая и utf-кодировок, но она точно может представить любой символ таблицы Юникода. И нам не нужно даже знать что это за кодировка, нам нужно знать какая кодировка на входе и на выходе программы.
У нас на входе и на выходе всегда байты. А именно:
- стандартные потоки ввода, вывода и ошибок, а также другие пайпы - это обычные байтовые потоки, которые работают ка коткрытые файлы, но являются пайпами на уровне системы и могут быть пернеправлены в реальные файлы в файловой сисеме.
- файлы - в файловой системе данные лежат в виде батов, и, в любом случае, нам нужно их как-то интерпретировать, если это текст.

Питон позволяет сделать обёртки вокруг файлового объекта, которые незаметно и прозрачно преобразовывают кодировки так что пользователь может в программе работать с юникодом не задумываясь о кодировках.
Всего лишь нужно правильно натсроить все эти обёртки и никогда не преобразовывать ничего вручную, а также не работать с байтовыми кодировками напрямую.

У вас, очевидно, self.task_name хранится в закодированном виде или некорректно преоразовывается.

Магии не бывает. Ничего там случайным образом с разу на раз не переключается. Если вы видете разные поведения в рахных ситуациях, то просто упускаете какой-то фактор. К примеру в винде запуск из bat-файла, запуск из консоли и запуск кликом мышкой в проводнике могут повлечь за собой запуск процесса с передачей ему пайпов стандартных потоков ввода вывода в разных кодировках. Если в программе мы этого не учитываем, то можем столкнуться с таким поведением как у вас.

Прологируйте значение вашего repr(self.task_name) перед взятием по ключу когда происходит ошибка и когда не происходит.
Вы увидите что меняется.

smilingcheater всё правильно написал. Дабвлю лишь, что нужно анализировать бутылочные горлышки и исправлять узкие места в первую очередь.
Разбирайтесь с проблемами детально. Что значит "nginx твалится"? Годами работает и ничего с ним не происходит. Выясняйте что произошло, если такое поторяется, то нужно разбираться, а не надеяться, что кто-то даст универасльный простой, но концептуальный совет, который победит все возможные проблемы наперед.
Правила тут простые: находим узкое место и расширяем его пока общая производительность в часы пик не будет удовлетворительной.
Надальте сохранение логов, протоколируйте нагрузки, помониторьте базу. Если проблема извне, то попробуйте подобрать хостинг понадёжнее, сменить OVZ на KVM, разнести БД и бэк на разные инстансы, прикрутите балансировщик,
Если где-то скорость не принципиальна и можно что-то отложить, добавляйте очередь.

Для этого используют структуру данных очередь (FIFO - First In First Out).
Туда будут добавляться таймштампы сообщений, а очередь должна хранить "минутное окно" этих таймштампов.
То есть последнее сообщение (в хвосте очереди) - это самое старое сообщение, а первое (в голове) - самое новое. Ко времени последнего сообщения на текущий момент прибавляем минуту и получаем время, когда нужно вытащить из очереди хвостовой элемент. Текущая длина очереди - это и есть количество сообщений за текущую минуту.
Это если вам надо без выравнивания.
Если нужно знать сколько сообщений было каждую минуту дискретно, то да, накапливаете счётчик и обнуляете его каждую целую минуту. Всё зависит от задачи.

По идее стандарт номера телефона, по которому отовсюду можно позвонить такой: "\+\d{11}".
Проблемы могут возникнуть с местными городскими соращенными номерами, там может быть и 5 цифр и 6 и 7 без кода города. Но если вы собираете номера телефонов по всему миру. то код города и страны вам все равно нужен,а значит 11-значный номер в любом случае будет правильным.
В разных местах по-разному ринято группировать цифры скобочками и дефисами. Но это к формату самого номера не относится, номер начинается с плюса и имеет 11 цифр. всё.
Из него взяв первую одну или больше цифр можно получить код страны, потом. для местных номеров, код региона, потом местный номер, но это лишнее, мне кажется. Берите одиннадцать цифр и всё.
Для разных стран можно предлагать пользователю разные форматы отображения и группировки цифр номера, но это уже прям можно сказать лишнее. Просто при вводе гнорируйте все кроме цифр, а плюс оставьте зафиксированным, чтобы люди догадались, что номер нужен в полном международном одиннадцатизначном формате.

Ну сначала следует один из списков превратить в словарь с ключом по идентификатору:

d1 = {item['user_id']:item for item in list1}
Потом превращаете в такой же словарь второй список, но по пути можно заодно и данные проапдейтить:

d2 = {
    item['user_id']:{
        **item, 
        **d1.get(item['user_id'], {})
    } 
    for item in list2
}

Теперь, если вам нужен-таки список обратно, то делаете из словаря список его значений:
list(d2.values())

Во втором питоне нужно будет по-другому делать, это для третьего вариант.

А что ваши функции возвращают по отрицательным веткам своих условий? Как вы ЭТО прибавляете?
Там же четко в сообщении сказано что присходит и в чем ошибка. Читайте же.