lukaszraczylo 5062017cf1 test(yaegi-check): probe a hung provider aborted under the interpreter ...

Adds exerciseRequestTimeout: a provider (hungtimeout) with an 80ms
ProviderConfig.RequestTimeout, backed by an upstream that stays silent
for 600ms. The request carries no client-side deadline of its own, so
a pass proves the gateway's own adapter-level timeout aborts the hang,
not a caller-supplied context.

This complements the existing slowProviderName probe, which proves a
CLIENT-set deadline classifies correctly. It does not prove the
adapter's own timeout mechanism runs correctly interpreted, since it
never exercises it without client help.

Verified the probe is not a no-op: temporarily removing
Transport.ResponseHeaderTimeout from newAdapterHTTPClient made make
yaegi-check fail with status 200 instead of 502. Reverted before this
commit.

timeoutProviderModel uses a distinct id, not testDataWantModel:
reusing it made the new provider win bare-id model resolution and
silently hijacked an unrelated existing probe.

2026-08-23 01:44:54 +01:00

..

pricing-sync

fix(pricing): content-digest snapshot instead of a wall-clock date

2026-08-22 02:12:29 +01:00

yaegi-check

test(yaegi-check): probe a hung provider aborted under the interpreter

2026-08-23 01:44:54 +01:00