Skip to content

fix(tests): webhook integration usa o envelope v2 (data era o corpo todo)#27

Merged
andrenfe merged 1 commit into
masterfrom
fix/webhook-integration-v2-envelope
Jul 10, 2026
Merged

fix(tests): webhook integration usa o envelope v2 (data era o corpo todo)#27
andrenfe merged 1 commit into
masterfrom
fix/webhook-integration-v2-envelope

Conversation

@andrenfe

Copy link
Copy Markdown
Member

Problema

A integration.yml (opt-in, manual) falhava em WebhookSignatureIntegrationTest:

assertSame('inv-123', $event->data['id'])  →  actual: 'evt-001'

O teste montava um payload flat ({type, data:{id:'inv-123'}, id:'evt-001'}) e esperava semântica de "data aninhado". Mas para payload flat o Webhook::constructEvent (corretamente) define data = corpo decodificado inteiro, então data['id'] = 'evt-001' (o id de topo), não 'inv-123'.

Era bug do teste, não do código. A semântica de data aninhado só existe no envelope v2 ({action, payload}) — o contrato real da API desde fix-account-webhooks-contract (#21). E é independente do PR #26 (expand-service-invoice-dto): constructEvent monta WebhookEvent direto, sem passar por hydrate().

Correção

  • O teste principal passa a usar o envelope v2data é o payload aninhado; as asserções type/id/data['id']/data['flowStatus'] voltam a passar e testam o contrato real.
  • Novo teste pina o fallback flat (data = corpo inteiro) — documenta os dois caminhos do constructEvent.
  • Event type atualizado para um id real (service_invoice.issued_successfully; os invoice.* não existem na API).

Verificação

  • Teste rodado localmente com env dummy (roundtrip HMAC é determinístico, não chama API): 3 passed.
  • CS e PHPStan limpos.
  • ⚠️ A ci.yml deste PR não roda a suíte de integração (gated por NFE_SDK_E2E, só na integration.yml manual). Após o merge, re-rodar a integration.yml para confirmar em CI — deve passar (a outra falha, CompaniesIntegrationTest, é config de secret NFE_SDK_E2E_COMPANY_ID / quirk do endpoint, tratada à parte).

…odo)

O teste `test_constructEvent_aceita_payload_assinado` montava um payload FLAT
(`{type, data:{id:'inv-123'}, id:'evt-001'}`) e afirmava `data['id'] === 'inv-123'`.
Mas para payload flat o `Webhook::constructEvent` (corretamente) define
`data = corpo decodificado inteiro`, então `data['id']` era `'evt-001'` — o teste
falhava na `integration.yml`.

Semântica de "data aninhado" só existe no **envelope v2** (`{action, payload}`),
que é o contrato real da API (fix-account-webhooks-contract). Correções:

- O teste principal passa a usar o envelope v2 → `data` é o `payload` aninhado;
  as três asserções (type/id/data['id']) voltam a fazer sentido e a passar.
- Novo teste pina o fallback flat (`data` = corpo inteiro) — documenta os dois
  caminhos do `constructEvent`.

Bug era só no teste; o código de `constructEvent` está correto. Não relacionado
à change expand-service-invoice-dto (constructEvent monta WebhookEvent direto,
sem passar por hydrate()).
@andrenfe andrenfe self-assigned this Jul 10, 2026
@andrenfe andrenfe merged commit 03dfc0f into master Jul 10, 2026
9 of 10 checks passed
@andrenfe andrenfe deleted the fix/webhook-integration-v2-envelope branch July 10, 2026 01:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant