Дмитрий
b28f858419
Прод-инцидент 11-12.07.2026: робот итоговой проверки слал письма «нет заказа у
поставщика» на строки, которые в кабинете ЕСТЬ, включены и с верным лимитом.
Корень: кабинет дописывает метку канала к имени строки только при СОЗДАНИИ, а при
обновлении сохраняет имя ровно как прислали. Наш ежедневный updateProject слал голый
uniqueKey и каждый прогон стирал метку. Последствия:
- итоговая проверка выводила площадку из префикса имени и переставала узнавать
строку -> ложное missing 11.07 и 12.07;
- лид от такой строки приходил с project без метки -> webhook не мог определить
канал и писал platform=DIRECT вместо B1/B2/B3, то есть терялась атрибуция канала.
Что сделано:
- SupplierPortalClient::toPayload — на update имя уходит с меткой канала; на create
остаётся голым, там метку ставит сам кабинет и один save с тремя флагами рождает
три строки, общего префикса у них нет.
- VerifySupplierOrderJob::normalizeLive — площадка берётся из служебного поля src
rt/bl/mt, а не из префикса имени; сверка больше не зависит от имени вообще.
- Новая разовая команда supplier:repair-project-names — возвращает метку строкам,
у которых её уже стёрли. Payload собирается ИЗ ЖИВОЙ строки кабинета, меняется
ровно одно поле name; по умолчанию сухой прогон, запись только с --apply.
Ветка пересобрана на gitea/main — закрывает follow-up «фича итоговой проверки заказа
не сведена в main». Попутно возвращён CsvReconcileJobTest, отставший от кода после
сведения main 09.07: он не фейкал fetchDeliveredLeads и падал 9 из 11.
Боевой liderra.ru: выкачено, починена 81 строка, робот показывает 0 расхождений
138 наших строк вместо 57. Двум лидам восстановлен канал по журналу выдач поставщика.
Тесты: Pest supplier 277/277, Pint clean, Larastan 0 новых ошибок.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
48 lines
1.8 KiB
PHP
48 lines
1.8 KiB
PHP
<?php
|
|
|
|
declare(strict_types=1);
|
|
|
|
use App\Mail\SupplierDeadlineWarningMail;
|
|
use Illuminate\Foundation\Testing\DatabaseTransactions;
|
|
use Illuminate\Support\Facades\DB;
|
|
use Illuminate\Support\Facades\Mail;
|
|
use Tests\Concerns\SharesSupplierPdo;
|
|
|
|
uses(DatabaseTransactions::class, SharesSupplierPdo::class);
|
|
|
|
beforeEach(function (): void {
|
|
DB::connection('pgsql_supplier')->table('supplier_sync_runs')->delete();
|
|
});
|
|
|
|
it('робот сегодня закончил → сторож молчит', function (): void {
|
|
Mail::fake();
|
|
DB::connection('pgsql_supplier')->table('supplier_sync_runs')->insert([
|
|
'started_at' => now(), 'finished_at' => now(), 'groups_total' => 1, 'synced_ok' => 1,
|
|
'manual_queued' => 0, 'deferred' => 0, 'failed' => 0, 'status' => 'ok', 'created_at' => now(),
|
|
]);
|
|
|
|
$this->artisan('supplier:deadline-watch', ['level' => 'yellow'])->assertExitCode(0);
|
|
|
|
Mail::assertNothingQueued();
|
|
});
|
|
|
|
it('робот сегодня НЕ закончил → красное письмо', function (): void {
|
|
Mail::fake();
|
|
DB::connection('pgsql_supplier')->table('supplier_sync_runs')->insert([
|
|
'started_at' => now(), 'finished_at' => null, 'groups_total' => 0, 'synced_ok' => 0,
|
|
'manual_queued' => 0, 'deferred' => 0, 'failed' => 0, 'status' => 'ok', 'created_at' => now(),
|
|
]);
|
|
|
|
$this->artisan('supplier:deadline-watch', ['level' => 'red'])->assertExitCode(0);
|
|
|
|
Mail::assertQueued(SupplierDeadlineWarningMail::class, fn ($m) => $m->level === 'red');
|
|
});
|
|
|
|
it('запуска за сегодня нет вовсе → письмо (планировщик не сработал)', function (): void {
|
|
Mail::fake();
|
|
|
|
$this->artisan('supplier:deadline-watch', ['level' => 'yellow'])->assertExitCode(0);
|
|
|
|
Mail::assertQueued(SupplierDeadlineWarningMail::class, fn ($m) => $m->level === 'yellow');
|
|
});
|