Как настроить формат даты и времени для анализа логов в goaccess?

Спасибо за ответ. Да не то что ищу, попросил помощи.
Стыдно конечно, но что поделать.
Проблема заключалась в локали, просто использование %b не работает:

If your access log contains English dates/months such as 12/Jan/2021 but your machine locale is not set to English, then you will need to set your LC_TIME

LC_TIME="en_US.UTF-8" bash -c 'goaccess access.log --log-format=COMBINED'

Будет мне уроком, сначала прочитать инструкцию до конца).

Как настроить формат даты и времени для анализа логов в goaccess?

Немного продвинулся, но проблема не решена.
Есть костыль, если везде по документу заменить в дате /Apr/ на /04/
тогда вот такой вызов работает исправно:

goaccess /path/logs/access.log --log-format='%h %^[%d:%t %^] "%r" %s %b "%R" "%u"' --date-format='%d/%M/%Y' --time-format=%T

Но это не вариант заменять строки руками, нужно искать правильный формат

Как обеспечить идемпотентность запросов к API?

Дмитрий, При чем тут контекст задачи и ваше непонимание работы сервиса ЮКасса?

В лк владельца сайта? То есть под клиентом подразумевается владелец сайта

Да, под клиентом, который делает заказ на сайте, подразумевается владелец сайта. У вас с головой все в порядке?
Я устал комментировать ваш бред. Не вижу смысла продолжать.

В качестве бонуса, как любителю цитат и анекдотов, адресую вам эту известную цитату:
Никогда не спорьте с дураками, они стащат вас на свой уровень и задавят опытом.
Эта цитата - контекст, которого вам так не хватает. И в рамках этого контекста сообщаю, вам удалось и первое и второе, и стащить на свой уровень и задавить опытом. Это победа.

Как обеспечить идемпотентность запросов к API?

Дмитрий,

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

Вот это тоже не верно. Вы НЕ понимаете как работает сервис, вот и всё.
Здесь можно ставить точку.

При ста попытках без "Idempotence-Key" будет создано 100 платежей, которые будут висеть в ЛК ЮКасса в статусе "Не оплачен". И только если 101 будет успешным, в аналитике будет 101 платеж.
100 в статусе "Не оплачен".
1 в статусе "Оплачен".
Это не предположение, это факт.
Я бы вам показал скрин, но в комментарий не приложить.

Я надеюсь это финал).
Вопрос здесь был задан, т.к. до этого момента, номера договоров не хранились в БД сайта, за ненадобностью.
Прежде чем писать код, я попросил сообщество поделиться опытом.
Без правок копирую из своего же вопроса:

Где все это время хранить созданный для этого Idempotence-Key?
Записать в куки, или работать с сессией, или писать в бд?
Как это делается правильно? Поделитесь пожалуйста опытом.

Поскольку это вырвано из контекста, поясню, вопрос "Как это делается правильно?" - не про то, как сохранить значение в базу. Надеюсь это понятно.

Александр Талалаев, чей ответ я отметил решением, дал конкретный ответ. Сразу. Понимаете?
Вы же втянули меня в такой блудняк.. но это было здорово). Уже в 10й раз говорю вам спасибо.
Ну, по рукам? Или опять не слава богу?

Как обеспечить идемпотентность запросов к API?

Дмитрий,

Сам id платежа, ну или ключ в этой дискуссии

Что значит "id ну или ключ" - ключ идемпонентности (Idempotence-Key) и id платежа (payment_id) - это разные вещи. Вы чего?

Давайте так.
Упростим просто для примера Idempotence-Key до номера договора.
Будем передавать номер договора, как значение заголовка "Idempotence-Key".
Это гарантирует, что объект платежа для этого номера договора будет создан только один раз.
При повторном запросе на создание платежа с этим же "Idempotence-Key", api вернет уже созданный платеж. Сервис НЕ будет создавать новый объект платежа для одного и того же "Idempotence-Key".

В ответе на успешно созданный платеж, будет содержаться его {payment_id}, по которому можно будет запросить информацию о платеже и его актуальном статусе.

Что из этого вам не понятно?

Как обеспечить идемпотентность запросов к API?

Дмитрий, А зачем отправлять запросы с одинаковыми параметрами и каждый раз создавать новый платеж?
Как может получиться, что клиент (человек на сайте), отправит данные дважды, повторяться не будем.
Только не надо говорить "А какая разница?", вопрос зачем? Зачем, по вашему, создавать новый объект платежа, если данные неизменны?

Зачем API ЮКассы обеспечивает идемпонентность запросов в 100% случаев?
Это ведь не такси, зачем это им? По вашей логике, это функционал поверх необходимого.
Напомню, что вы не сможете обратиться к API ЮКассы без ключа. Никак.

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

Как обеспечить идемпотентность запросов к API?

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

мы ж блин говорим об официальной библиотеки

Нет. Это вы говорите о библиотеке (Клиенте), я говорю о сервисе API, с которым этот Клиент работает.

Никакая имподентность вам нахрен не нужна

Я не спрашивал нужна или нет. Вы не найдете такого вопроса здесь.

Некоторые ваши пояснения вообще за гранью:

я вам несколько раз написал кто генерирует ключ

Где вы нашли вопрос от меня "Помогите понять кто должен генерить ключ?".
Зачем и главное кому, вы "несколько раз" это написали?!
Вопросы риторические, отвечать не нужно. Разве только себе.

Прочитайте внимательно вопрос и описание вопроса этого поста. Не этого комментария, а главный вопрос страницы.
Обратите внимание, как адекватные люди, без дополнительных вопросов и демагогии, неуместных шуток, анекдотов, пятой ноги у собаки и т.п., быстро и точно дали ответ на вопрос поста. Задумайтесь над этим.

Услышьте меня. Спасибо за все.
Тут много воды, но есть и полезное, я вам за это благодарен.

Чтобы у вас не осталось осадка, что я не ответил на ваши два максимально простых вопроса, отвечу.
Но извините, если вам не понравится. С этим помочь не смогу.
Итак - я НЕ смогу ответить вам более подробно, чем описано в статье "Стажёр Вася и его истории об идемпотентности API", ссылку на которую я давал вам выше.
Если вас что-то не устраивает, не понимаете зачем это нужно, не считаете это обоснованным, не желаете этим пользоваться и что угодно другое - отлично, вы молодец.

Как обеспечить идемпотентность запросов к API?

Дмитрий,

Да при каждой попытке оплаты они будут генерить ключ.

Вы вообще со мной разговариваете? Ответы сервиса видите? - Нет!!! Сервис НЕ будет генерить ключ. Вообще. Никак. Точка! Он будет возвращать "invalid_request". Очнитесь.

Генерит ключ каждый раз исключительно Клиент, но не API, на который Клиент шлет запросы. Обратиться к API без ключа не получится.
Нужна вам идемпонентность или нет, решайте сами для своих проектов.
Я задал здесь вопрос и адекватные люди на него ответили ниже.
Вам респект, что не сдаетесь, даже по бреду.

На этом все. Дальше можно только ходить по кругу.
Проспитесь и предложение за предложением перечитайте этот диалог, поймете как работает сервис, клиент, что такое идемпонентность и зачем она нужна. Дальше решите нужна ли она лично вам. Успехов.

Как обеспечить идемпотентность запросов к API?

Дмитрий, Еще довольно смешной момент). Вы приводите мне цитату, текст из документации, который я должен был прочитать, если бы пошел "чуток дальше первой строчки".
Вот ваш текст:
"А если взять и пойти чуток дальше первой строчки документации: это можно прочитать.."

Но это именно тот текст, который я отправил вам в ответ на самый первый ваш комментарий.
Согласитесь это смешно).
Получается, если бы пошли чуток дальше первой строчки, вы бы увидели тоже самое)), что потрудились скопипастить из доки мне.

Как обеспечить идемпотентность запросов к API?

Дмитрий, Мое почтение за глубину погружения.

По первому пункту "...если пойти чуток дальше первой строчки документации" - спасибо, но это именно то, что я вам скидывал и хотел, чтобы вы прочитали. Вы молодец, справились.

Код вижу, и это самое интересное.
Игнор и принудительная генерация ключа реализована (внимание) только в клиенте.
Т.е. через оф. клиента платеж будет создан в любом случае, это видно в исходниках и я провел тесты.

Но..
Прямые запросы к API, стабильно возвращают ошибку в обоих случаях, и если Idempotence key не передан вовсе и если передан со значением null. Такие дела).
Ответ сервиса на запросы без ключа всегда одинаковый - "Invalid request: Idempotence key is missing. Generate a unique key is specify it in the Idempotence-Key header".

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

Отвечая на вопрос "Зачем отправлять повторно с тем же ключом?"
Например, у клиента слабый мобильный интернет, он едет в автомобиле, заполняет данные формы, нажимает "Оплатить", оправляется запрос на создание платежа, но ответ не успевает вернуться клиенту, т.к. инет слабый и ровно в этот момент он въезжает в туннель, где связь пропадает. Клиентский скрипт отрабатывает, выдает уведомление, разблокирует кнопку оплаты и предлагает отправить запрос повторно. На выезде из туннеля клиент нажимает кнопку повторно, с теми же данными и тем же ключом. Тогда сервис отвечает уже созданным объектом платежа, срабатывает логика и клиент направляется на страницу оплаты ЮКасса, если реализовано именно такое поведение. Просто сервис предлагает разные варианты.
Туннель, лифт, подземный переход.. что угодно в связке со слабой мобильной связью.

Как обеспечить идемпотентность запросов к API?

Дмитрий, Уважаемый, спасибо за вашу активность. Я не сам себе изобретаю, что нужно, а что нет для создания платежа. Ключ идемпонентности - обязательный параметр. Это требует платежный сервис, понимаете? Посмотрите документацию.
Пятая нога, шестая или другая - объясните это разработчикам сервиса, ок?

Давайте без шуток, в благодарность за ваши комментарии (вы же хотели помочь, верно?), показываю результат обращения к сервису, без ключа идемпонентности. Это запрос на создание платежа:

{
  "type" : "error",
  "id" : "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "code" : "invalid_request",
  "description" : "Idempotence key is missing. Generate a unique key is specify it in the Idempotence-Key header",
  "parameter" : "Idempotence-Key"
}

Расскажите потом, удалось убедить разрабов сервиса, что ключ не нужен, лишний и вот эту историю с собакой. Тут всем будет полезно.

Как обеспечить идемпотентность запросов к API?

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

Как обеспечить идемпотентность запросов к API?

Александр Талалаев, Спасибо за советы, помечу ваш ответ как решение.

Как обеспечить идемпотентность запросов к API?

Александр Талалаев Спасибо за ответ, все очень точно описано, весь функционал в шлюзе сервиса есть.
Нет, не использую плагины, тут это не нужно, подключается один единственный способ оплаты, как дополнительный, к уже имеющимся. Плагин потянет за собой тонну неиспользуемой функциональности.
Получается - писать в БД. Решение понятно.
Пара вопросов.
Сайт без регистрации, как связать именно "этого" клиента с записью покупки в базе?
Например, произошел какой-то лаг, клиент обновил страницу или даже не обновлял, но отправил запрос повторно. Как связать, что это именно он, именно его заказ есть в базе со статусом "Не оплачен"?
Просто генерить уникальную запись для каждого обращения к шлюзу - проблем нет, для этого и БД не нужна, тут же вся суть, если я правильно понимаю идемпотентность, чтобы повторный заказ с теми же параметрами от одного клиента, выдавал один и тот ответ сервиса. Не плодил сущности платежа, каждый раз создавая новый, а возвращал уже созданный платеж в статусе "Pending".

Как обеспечить идемпотентность запросов к API?

Дмитрий, Такое поведение помогает избежать нежелательного повторения транзакций. Например, если при проведении платежа возникли проблемы с сетью, и соединение прервалось, вы сможете безопасно повторить нужный запрос неограниченное количество раз.
Вот здесь увлекательная история об идемпотентности.

Чем заменить тег br?

Тег <br> такой же тег, поставьте его в нужном месте, дайте ему класс и через css управляйте, когда его применять, а когда нет. Через свойство display.

Не подключаются файлы дочерней темы wordpress?

bingumd, спасибо, буду знать. Действительно, в родительской теме файл подключен через require.
К сожалению комментарий нельзя отметить, как решение. Если хотите, напишите в "Ответы", я отмечу.

Как стриггерить обновление данных при прямом изменении их в БД wordpress?

azerphoenix, Anton Semenov, Спасибо за ответы. Нет, все это я понимаю, кэш плагинов, cdn и т.п., это исключено.
Снял дамп базы, нашел эти старые записи в таблице "wp_yoast_indexable", надо узнать зачем она нужна, можно ли ее просто очистить или нужно обновлять данные в ней?

Как сделать input в таблице шириной его содержимого?

Уважаемый, большое вам спасибо!

Что значит такая запись в логе хостинга для сайта?

Спасибо, Timofey!