Зависящие друг от друга POST-запросы во второй фазе

[evis]

Вроде говорили, что во второй фазе не будет зависящих друг от друга запросов. В то же время в TRAIN-данных вижу следующее:

379 POST:/locations/new
<...>
{"id": 838, <...>}

<...>

207 POST:/visits/<entity_id>
<...>
{<...>, "location": 838}

Если сначала обработать первый запрос, второй вернёт 200; если сначала второй, то он должен вернуть 400.

Также конкретно сегодня на тестовом прогоне как минимум я и @AterCattus получили во второй фазе сначала обновление юзера 1006, а потом уже создание (id моего решения 12984)

[PumbaOmsk]

подтверждаю. 20.08.2017 много раз ловил обновление 1006 юзера с ошибкой.

[dimkk]

Подтверждаю с 1006

[ewgRa]

по 1006 тоже иногда возникает, по логам там сначала создание, потом обновление, но они настолько рядом видимо, что у меня создание не успевает, и на обновление 404 отвечает

[zuko3d]

@ewgRa Специально в один из заходов поставил у себя всю обработку в один поток - всё равно иногда не находит 1006, а иногда находит. Такое ощущение, что от обстрела к обстрелу порядок "выстрелов" меняется.

[evis]

@zuko3d, думаю, что скорее дело в том, что танк может в несколько потоков кидать запросы и тогда даже в твой один поток они всё равно в рандомном порядке приходят.

[zuko3d]

@evis да, тоже об этом думал. Только мне не совсем ясно, то ли это баг тестирующей системы (подаётся запрос на обновление несуществующего пользователся и ожидается код не 404, а 200), то ли моё решение (как и моё понимание условий) неверно.

[sat2707]

Пересобрали генератор данных, теперь во второй фазе пост-запросы не зависят друг от друга