Skip to content

Scope REST response metadata to the active session - #1469

Open
efegokdemir wants to merge 1 commit into
Shopify:mainfrom
efegokdemir:efe/rest-resource-state-scope
Open

efegokdemir wants to merge 1 commit into
Shopify:mainfrom
efegokdemir:efe/rest-resource-state-scope

Conversation

@efegokdemir

Copy link
Copy Markdown

Description

Fixes #1365

REST resource response metadata is stored per thread, so a worker reused for another request can expose pagination or rate-limit values from the previous session. This change tags each response's metadata with the current session-lifecycle generation and makes the resource getters return nil when that generation changes. Values remain available throughout the same lifecycle.

How has this been tested?

  • bundle _2.5.9_ exec rake test:library — 343 runs and 687 assertions passed.
  • bundle _2.5.9_ exec rubocop lib/shopify_api/context.rb lib/shopify_api/rest/base.rb test/clients/base_rest_resource_test.rb — no offenses.
  • The regression test failed on the unmodified implementation because next_page? stayed true after switching sessions; it passes with this change.
  • Ruby syntax checks and git diff --check passed.
  • Sorbet typechecking could not run: the locked static binary is x86_64 and this host is ARM.

Checklist:

  • My commit message follow the pattern described in here
  • I have performed a self-review of my own code.
  • I have added tests that prove my fix is effective or that my feature works.
  • I have updated the project documentation.
  • I have added a changelog line.

@github-actions github-actions Bot added the devtools-gardener Post the issue or PR to Slack for the gardener label Oct 11, 2026

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

devtools-gardener Post the issue or PR to Slack for the gardener

Projects

None yet

Development

Successfully merging this pull request may close these issues.

REST resource state persisting between job/request executions within the same thread

1 participant