[erkancamli]

Motivation

fulfillOrders is documented as best effort, and #985 made it drop cancelled and fully filled orders so one stale order does not take the whole batch down. Expired orders were left in.

Seaport treats an expired order the same way as a cancelled one in fulfillAvailableAdvancedOrders: it skips it and settles the rest. The SDK still builds the call with the expired order inside, so that order is:

• checked against its offerer's current balance and approvals,
• added to the fulfiller's cumulative ERC20 balance check,
• added to the native value sent.

That makes one lapsed order enough to block a batch the contract would settle. Two cases, both reproduced on the hardhat fixture at 589c6b8:

1. Two listings from one seller, one of them expired, and the seller has since moved the expired listing's NFT. fulfillOrders throws The offerer does not have the amount needed to create or fulfill. Calling fulfillAvailableAdvancedOrders on the Seaport contract with the same two orders returns availableOrders [false, true] and transfers the live listing's NFT for exactly its price.
2. Two ERC20 listings, one expired, and a fulfiller holding enough for the live one only. fulfillOrders throws The fulfiller does not have the balances needed to fulfill. although only the live order would be charged.

Expiry is the most common way an order goes stale between reading it and filling it, which is the case this method exists for.

Solution

Drop an order from the batch when its endTime is at or before the latest block timestamp, alongside the cancelled and filled ones (hasOrderExpired next to isOrderFulfillable). Block time only moves forward, so an order that has expired at the latest block is still expired when the transaction lands, which matches Seaport's startTime <= block.timestamp < endTime window. Orders that have not started yet are kept, because they can become active by the time the transaction is mined.

If every order is dropped the existing "None of the orders can be fulfilled" error is thrown, now naming expiry too, instead of sending a transaction that reverts with NoSpecifiedOrdersAvailable().

Single order fulfillOrder is unchanged.

Tests:

• fulfill-orders-availability.spec.ts: an expired listing whose NFT the seller moved no longer blocks the live listing, and the value sent is only the live listing's price; an expired ERC20 listing is no longer counted against the fulfiller's balance, and the live one settles on chain with the fulfiller's exact balance.
• fulfill-utils.spec.ts: hasOrderExpired boundaries (before, at and after endTime, and a not yet started order).

Both new integration tests fail on main with the errors above and pass with the change. Full suite: 305 passing, tsc --noEmit clean, biome check . clean apart from the existing config migration info.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.17%. Comparing base (f618d19) to head (d452577).
⚠️ Report is 430 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1063      +/-   ##
==========================================
+ Coverage   98.27%   99.17%   +0.89%     
==========================================
  Files          35       60      +25     
  Lines       14526    22200    +7674     
  Branches      660     1284     +624     
==========================================
+ Hits        14276    22017    +7741     
+ Misses        245      176      -69     
- Partials        5        7       +2     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ryanio]

Thanks for this. I checked it against current main: both integration tests fail without the change, with the errors you described, and pass with it. Lint, tests and coverage are green. Merged, and it will go out in the next release.