Beispiel

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

sha256:ba99fb2bf3dcbb90f9cfeb92673322d9bb85a7bdef5493050f6dd3a779abd62d

Fall

Ziel

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

Pakete

faraday 2.14.3

Umgebung

ruby

Erstellt

2026-08-17T02:39:03Z

Häufige Annahme

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

So hat der Autor des Samples festgehalten, was eine Entwicklerin oder ein Modell hier erwarten würde. Der Vertrag darunter ist das, was tatsächlich lief.

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

Dateien

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

Verifiziertes Artefakt herunterladen (tar.gz) — genau die Bytes, gegen die der Contract lief

Ursprungs-Seeder

csx-seed

Verifizierungsbelege

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