Skip to content

Refactor SessionStore usage to explicit, typed execution contexts #29

@pratmehta89

Description

@pratmehta89

Background / Problem
The framework leans on the legacy SessionStore singleton, which silently stuffs attributes into a shared dict via setattr. This hides dependencies, is fragile under parallel execution (xdist workers, threads), and makes state flow opaque. It also forces consumers to rely on environment variables/global state, complicating testing and extension.

What’s Needed

  1. Introduce a dataclass-based execution context (e.g., SessionContext) that holds state for tests, drivers, reporting, etc.
  2. Expose that context intentionally - either passed into hooks/services or retrieved via a registry/context manage - rather than via a global singleton.
  3. Guard attribute writes: retire free-form setattr in SessionStore (or remove the class entirely) in favor of an allowlist or explicit API that maps to the context fields.
  4. Update hooks (pytest_* modules) and downstream layers (UI clients, reporting, config utils) to depend on the explicit context.
  5. Ensure compatibility during migration: maintain a compatibility wrapper if needed while consumers are gradually moved.

Acceptance Criteria

  1. Execution state is represented by a typed context object rather than the current dict-backed singleton.
  2. Hooks receive or obtain that context explicitly; no new code writes arbitrary attributes on SessionStore.
  3. Attribute access is validated - attempts to set unknown properties raise errors (guarded allowlist or explicit setter methods).
  4. All existing functionality (report generation, step decorators, UI driver management, etc.) works without relying on environment variables or SessionStore().storage.

Out of Scope / Follow-ups (optional)

  1. Migrating to a contextvars/per-worker registry for thread/process isolation (tracked separately if needed).
  2. Removing the singleton entirely once all consumers depend on the new context

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions