Skip to content

fix: key lifecycle state by Click context - #399

Open
codeforester wants to merge 2 commits into
mainfrom
bug/383-20260930-bug-lifecycle-state-keyed-by-id-click-context-can-be-misattr
Open

codeforester wants to merge 2 commits into
mainfrom
bug/383-20260930-bug-lifecycle-state-keyed-by-id-click-context-can-be-misattr

Conversation

@codeforester

Copy link
Copy Markdown
Contributor

Fixes #383

# Keep the context object itself as the key. ``id(context)`` values can be
# reused after Click releases a context, which could associate a later
# invocation with stale lifecycle values.
context_values = captures.setdefault(click_context, {})

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Test gap: issue #383's acceptance criteria explicitly require "a regression test exercises a chain=True group with per-command lifecycle values and asserts each command observes its own resolved values, with the intermediate contexts released between members." The new test (tests/test_click_tree_attachment.py) only exercises _capture_lifecycle_option() with a bespoke FakeContext double, not a real chain=True group with context teardown/GC timing. If a future refactor reintroduces id()-based keying, or this fix is subtly wrong under real Click context lifecycle (vs. the synthetic double), the suite would still pass and the misattribution bug could ship silently again.

# Keep the context object itself as the key. ``id(context)`` values can be
# reused after Click releases a context, which could associate a later
# invocation with stale lifecycle values.
context_values = captures.setdefault(click_context, {})

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Design note: this fix satisfies "no id() reuse" but doesn't address issue #383's other acceptance criterion that "memory behaviour for a long chain is documented or bounded." The capture/resolution dicts still grow one entry per context for the invocation's life, and now pin full Context objects alive (via the shared meta dict) rather than lightweight int keys. A chain=True invocation with a very large number of subcommands now keeps one live Context object per command alive for the whole invocation, with no comment/doc acknowledging or bounding this, despite the issue calling it out as required.

This branch has not been deployed

No deployments
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.

bug: lifecycle state keyed by id(click_context) can be misattributed after context reuse

1 participant