Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#1,365 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

@efegokdemir arbeitet bereits daran.

Seit 11.10.2026.

  • #1469 von @efegokdemir — offen

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
35/100
Issue-Typ
Bug
Klarheit
Muss geklärt werden
Aktivitätsstatus
Veraltet
Tech-Stack
ruby
Bereich
api, backend

Rechercherichtung

Beginne damit, die Behandlung des Zustands von REST-Ressourcen in lib/shopify_api/rest/base.rb zu lesen, insbesondere die verlinkten Zeilen 125-153. Ermittle, wie der Zustand von Klasseninstanzen über Requests oder Jobs hinweg bestehen bleibt, und definiere dann einen Rücksetz- oder Isolationspunkt, damit der Zustand aus einer früheren Ausführung, einschließlich eines anderen Shops, nicht vor einem neuen Request wiederverwendet wird.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Issue summary

By default, rails applications in production will not reload constants & classes between requests or
between execution of background jobs. This means that certain data stored within class instance variables on the REST
resources (see the base resource here)
will not be reset when a given thread completes processing a request or job, and begins to process another.

To illistrate where this could be an issue, consider a simple class that might be used throughout an application to
fetch product information for a Shop:

class FetchProducts
  class << self
    def call
      return if rate_limit_reached?

      ShopifyAPI::Product.all
    end

    private

    def rate_limit_reached?
      limits = ShopifyAPI::Product.api_call_limit

      return false unless limits.is_a?(Hash) && limits[:request_count] >= limits[:bucket_size]

      true
    end
  end
end

If no prior Product API calls have been made within the context of current job or request, it would be reasonable
to expect ShopifyAPI::Product.api_call_limit to be nil since we haven't made a request yet, and therefore there have
not received a response with any rate limiting headers.

However since api_call_limit is stored within a class instance variable within the ShopifyAPI::Product class,
if the current thread has previously processed a separate request or job that used the ShopifyAPI::Product
class to fetch products, then the response headers from that prior request will stil be present in the class.

It's entirely possible that this prior job or request pertained to an entirely separate shop, and thus the stored
rate limit headers would not be applicable within our current job / request.

The implication of this, is that it's not safe to check values stored in the class instance state of the REST resources until after a request has been made through that same class.

Vorherrschende Sprache
Ruby
Sterne
1.1k
Forks
487
Ø Merge
1 T. 2 Std.
Gemergte PRs (30 T.)
2

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus Shopify/shopify-api-ruby

Alle Issues in Shopify/shopify-api-ruby

Ähnliche Issues

Weitere Issues zu Ruby

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.