Skip to content

Close the application-returned WSGI iterable - #27

Merged
kentbull merged 1 commit into
release/v0.6.20from
fix/http-wsgi-iterable-close-v0.6.20
Aug 29, 2026
Merged

kentbull merged 1 commit into
release/v0.6.20from
fix/http-wsgi-iterable-close-v0.6.20

Conversation

@kentbull

@kentbull kentbull commented Aug 29, 2026 •

Copy link
Copy Markdown
Collaborator

Summary

  • retain the WSGI application-returned iterable separately from its derived iterator
  • close the returned cleanup owner exactly once across normal and explicit-abort terminal paths
  • clear retained references before cleanup so recurrent close cannot repeat resource release
  • treat cleanup failure as producer failure before terminal chunk framing

Why

PEP 3333 requires the server to call close() on the iterable returned by the application. HIO previously discarded that object and retained only iter(iterable), which may be a distinct object with a different or absent cleanup contract.

Tracks ioflo#192.

The behavior is generically upstreamable, but the code port is deferred until upstream PRs ioflo#179 and ioflo#181 plus the implementation of ioflo#191 land.

Retain the object returned by the WSGI application separately from its derived iterator so HIO can satisfy the PEP 3333 cleanup contract. Close that owner exactly once across normal completion and explicit termination without mistaking iterator cleanup for application resource release.
@kentbull
kentbull merged commit baefa19 into release/v0.6.20 Aug 29, 2026
6 checks passed
@kentbull
kentbull deleted the fix/http-wsgi-iterable-close-v0.6.20 branch August 29, 2026 22:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant