Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#1,365 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
ruby
Área
api, backend

Línea de trabajo

Comienza leyendo el manejo del estado de los recursos REST en lib/shopify_api/rest/base.rb, especialmente las líneas enlazadas 125-153. Determina cómo persiste el estado de las instancias de clase entre requests o jobs y, después, define un punto de restablecimiento o aislamiento para que el estado de una ejecución anterior, incluido el de otra tienda, no se reutilice antes de un nuevo request.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Ruby
Estrellas
1.1k
Forks
484
Merge medio
4 h 38 min
PR fusionados (30 d)
1

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Shopify/shopify-api-ruby

Todos los issues de Shopify/shopify-api-ruby

Issues similares

Más issues de Ruby

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.