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

Можно переписать через httptest.NewServer() и defer server.Stop(), это значительно ускорит прохождение тестов и избавит от костылей вроде NewHost() и LastHost()

Было бы неплохо создать какой-то глобальный контекст сервера, чтобы не только в хендлерах его получать, но и раньше, он может пригодиться при инициализации хранилища(во время инициализации БД)

          Все операции с внешними ресурсами - потенциально долгие, так что лучше нам ими управлять, для того контекст и может пригодиться

Originally posted by @EsdeathEsdeath in #25 (comment)

          Это, все же не должно лежать в `main`

Originally posted by @EsdeathEsdeath in #18 (comment)

В сервисе отправки сообщений с агента существует архитектурная проблема. В текущем контракте мы записываем в тело сообщения объект интерфейса io.Reader, это позволяет компрессирующей мидлвари правильно взять объект из тела сообщения(используем resty.SetBody(), где передается any).

Потом мы добавили фичу с повторной отправкой, она работает вот так

sendCall := func() error {
	var err error
	resp, err = defaultClient.R().SetBody(buf).Post(url)
	return err
}

Эта функция срабатывает три раза.

И что происходит. Во время первого запуска, она читает buf типа io.Reader, во время второго запуска она опять читает buf, но поскольку это поток, то теперь buf пустой. Об этом сообщает даже компрессор, которому приходят на сжатия пустые сообщения. То есть остальные три попытки мы уже пытаемя отправить невалидные сообщения. Уже проверено, что сервер их не принимает с ошибкой EOF

Нужно либо перекататься на использование []bytes

По сути метрики это не только тип данных, но ещё и поведение, и конечно стоило бы выделить их в отдельный пакет, конечно, чтобы у них была функция вроде Process

var c metrics.Counter
Counter.Process(value)

type Metricer[T any] interface {
    Process(T value)
    ProcessString(s sring) //обрабатывает на 
    FromString(s String) //? может быть!
}

Но зачем это пока не понятно, не буду я путаться в создании всех этих метрик или буду, короче хз полное

В chi есть отличная AllowContentType(), которая позволит сделать проверку на text-plain, когда тесты починят конечно. Но тот срашный зеленый кусок кода можно отменить

При сохранении счетчика PollCount на сервере, его новое значение прибавляется к уже имеющемуся. Но и на клиенте происходит то же самое, таким образом, значение счетчика растет в арифметической прогресси, вместо прямой

Нужно понять, где мы инкрементируем счетчик

Если буфер слишком маленький, то подпись не сможет быть проверена. потому что в нее не весь реквест влезет.

см. SignBufferSize в мидлварях

попробовать как работает .http в VSCode, это расширение в котором можно записать отправку запросов преподготовленных

В данный момент батчи парсятся обычным парсером встроенным. Это медленнее, тем временем уже назрело использование какой-то именованной структуры для []metrica.Metrica, например ещё она может иметь метод Squash(), который сжимает метрики до минимально полезного(сложить каунтеры и заменить гаужи при совпадени имен).

          Вот такое избегаем, хотя бы `log.Fatal`

Originally posted by @EsdeathEsdeath in #18 (comment)

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

Как оказалось, агент тоже пользуется логикой сохранения метрик, а это значит, что логику, что counter должен увеличивать значение, а gauge обновлять стоит записать в какой-то общий блок. Я бы воспользовался MemStore для этого.

А лучше даже сделать это в интерфейсе Storer. Он же знает как сохранять и вызывать значение, значит сможет и хранить логику для него. Не знаю насколько это зашквар.

Плюс сервер, надо переписать так, чтобы он пользовался именно интерфейсомstorer

Ключ так парсится, что его легко случайно вывести в консоль случайно, а из логов его увидят злоумышленники.

Может быть сделать какой-то специальный тип данных, который имел бы тип Stringer, но возвращал звездочки. Я бы даже может возвращал не сам ключ, а коллбек возвращающий ключ, чтобы он там не попал куда не следует случаем

А ещё можно вывести конфиги в отдельный пакет, и там ключ сделать внутренней переменной, чтобы совсем не было шансов

          Надо бы сделать нежное завершение и для агента

Originally posted by @thefrol in #39 (comment)

Попробовать goose как интрумент для миграций

          Это лучше отсюда убрать хотя бы в условный `cmd/server/init.go`, `main` должен быть максимально компактным

Originally posted by @EsdeathEsdeath in #18 (comment)

          А если у нас и `ListCounters()` и  `ListGauges()` имеют одинаковую сигнатуру, то может их объединить?

Originally posted by @EsdeathEsdeath in #18 (comment)

Мы должны отправить сколько раз мы считали данные из памяти. Больше ничего. И не обязательно это отправлять одновременно с остальными данными. Главное если считали пять раз, то пять раз и отправили. Как например, если ошибка случилась пять раз, то мы пять раз и отправляем.

В данный момент, с учетом асинхронного сбора, можно заметить, что поллкаунт вообще не нужно сбрасывать. Агент вообще ничего не должен знать про логику метрик, он знает только о формате данных для отправки. Поэтому фактически если мы кидаем в очередь поллкаунт, то это всегда должно быть 1. Надо и пакет поллкаунт убрать

Когда завершается агент. Количество активных горутин -3. Что это?

Хорошо бы сделать какие тесты, но как например флаги тестировать я не понимаю пока