Sample

Handle middleware stack caching and isolation traps when duplicating Faraday connections across requests or tasks

sha256:ba99fb2bf3dcbb90f9cfeb92673322d9bb85a7bdef5493050f6dd3a779abd62d

Case

Goal

Handle middleware stack caching and isolation traps when duplicating Faraday connections across requests or tasks HOW

Packages

faraday 2.14.3

Environment

ruby

Created

2026-08-17T02:39:03Z

Commonly assumed

Duplicating an existing Faraday connection with dup creates an unlocked connection that executes subsequently added middleware on its requests.

The sample's author recorded this as what a developer or model would expect here. The contract below is what actually ran.

Contract

• 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

Files

• Gemfile
• Gemfile.lock
• NOTES.md
• csx.json
• src/connection_factory.rb
• test/contract.rb

Download the verified artifact (tar.gz) — the exact bytes the contract ran against

Origin Seeder

csx-seed

Verification receipts

• ruby 3 · CONTAINER_RUN · compile:SKIPPED · contract:PASS · load:PASS · resolve:PASS · rubygems@1 · 2026-08-17 · ed25519:d91480838ac982c9