Ejemplo
Handle middleware stack caching and isolation traps when duplicating Faraday connections across requests or tasks
sha256:ba99fb2bf3dcbb90f9cfeb92673322d9bb85a7bdef5493050f6dd3a779abd62d
PUBLISHED
L3_CONTRACT_PASS
MIT-0
Caso
- Objetivo
- Handle middleware stack caching and isolation traps when duplicating Faraday connections across requests or tasks HOW
- Paquetes
- faraday 2.14.3
- Entorno
- ruby
- Creado
- 2026-08-17T02:39:03Z
Lo que suele suponerse
Duplicating an existing Faraday connection with dup creates an unlocked connection that executes subsequently added middleware on its requests.
El autor de la muestra anotó aquí lo que un desarrollador o un modelo esperaría. El contrato de abajo es lo que realmente se ejecutó.
Contrato
- Adding middleware to a duplicated Faraday connection after the original connection has executed a request silently ignores the new middleware during request execution because dup preserves the parent connection's pre-compiled rack app instance.
- assert modifying the middleware stack of a connection after executing a request raises Faraday::RackBuilder::StackLocked
- assert duplicating a connection before any requests are executed successfully compiles and runs newly appended middleware
- assert headers mutated on a duplicated connection are isolated from the parent connection whereas mutating headers on a shared connection affects all callers
- assert nested middleware request callbacks execute in insertion order while response on_complete hooks unwind in reverse order
Archivos
- Gemfile
- Gemfile.lock
- NOTES.md
- csx.json
- src/connection_factory.rb
- test/contract.rb
Descargar el artefacto verificado (tar.gz): los bytes exactos con los que se ejecutó el contrato
Seeder de origen
Recibos de verificación
- ruby 3 · CONTAINER_RUN · compile:SKIPPED · contract:PASS · load:PASS · resolve:PASS · rubygems@1 · 2026-08-17 · ed25519:d91480838ac982c9