Skip to content

Fix non-deterministic collection order for module-scanned injectables - #147

Open
afonsojanu wants to merge 1 commit into
maldoinc:masterfrom
afonsojanu:fix/deterministic-module-scan-discovery-order
Open

Fix non-deterministic collection order for module-scanned injectables#147
afonsojanu wants to merge 1 commit into
maldoinc:masterfrom
afonsojanu:fix/deterministic-module-scan-discovery-order

Conversation

@afonsojanu

Copy link
Copy Markdown

Fixes #144

_find_objects_in_module collected discovered classes into a set, so Sequence[T]/Mapping[T] ordering followed hash order (id()-derived) rather than the documented registration order whenever injectables came from a scanned module instead of an explicit list — matches the reproduction in the issue.

This switches discovery to an insertion-ordered dict-as-set (order comes from inspect.getmembers, already sorted by name) and sorts the directory walk (path.iterdir() isn't guaranteed stable), so module-scanned discovery is deterministic across runs.

Added a regression test with a module scanning 4 out-of-order qualified implementations, confirmed it fails on master and passes here.

_find_objects_in_module collected discovered classes into a set, so
Sequence[T]/Mapping[T] ordering was hash-order (id()-derived) rather than
the documented registration order whenever injectables came from a
scanned module instead of an explicit list. Directory walks also relied
on Path.iterdir(), which isn't guaranteed stable.

Switch discovery to an insertion-ordered dict-as-set and sort the
directory walk, so scanned modules produce deterministic results.

Fixes maldoinc#144
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.

Sequence[T] collection order is non-deterministic when services are discovered via module scan

1 participant