Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[BUG] Aws::Record::ItemCollection intermittently returns nil/raises from to_a and each

Aperta
  • Qualcosa non va?
#153 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
aws, ruby
Ambito
databases

Direzione di ricerca

Inizia da aws-record-2.14.0/lib/aws-record/record/item_collection.rb, in particolare da each alla riga 28, e riproduci il problema con Model.build_query.complete!, seguito da to_a o each. Traccia il modo in cui la collection ottiene il proprio Aws::PageableResponse e analizza il percorso each_page nil segnalato. Il lavoro è completato quando le query DynamoDB riuscite possono sempre essere enumerate senza risultati nil né eccezioni.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

feature-request p2 queued
Describe the feature

Please harden Aws::Record::ItemCollection so it always honors the Enumerable contract. Today, calling to_a or each on a collection returned by Model.build_query.complete! can either raise or return nil, even when DynamoDB succeeded. The library should guarantee that enumerating a query result never blows up unless the service call itself failed.

Use Case

Every app using aws-record expects query.complete! to behave like a normal enumerable. In production we see sporadic NoMethodError: undefined method 'each_page' for nil:NilClass and cases where collection.to_a literally returns nil. That breaks paging, query helpers, and forces us to wrap every call site in defensive code just to prevent random 500s.

Proposed Solution

Ensure ItemCollection#each always has a backing Aws::PageableResponse and never returns nil.
Concretely:

  • Don’t mutate @items out from under each; memoize the client response before iterating.
  • Guard items.each_page with a lazy initializer so it never operates on nil.
  • Consider adding internal retries if the SDK hasn’t populated the items accessor yet.

As an immediate workaround we had to wrap the result:

def safe_array(result)
Array(result.to_a)
rescue StandardError
result.each_with_object([]) { |item, memo| memo << item }
rescue StandardError
[]
end

…but that’s brittle and doesn’t belong in every consumer.

Other Information
  NoMethodError: undefined method `each_page' for nil:NilClass
    aws-record-2.14.0/lib/aws-record/record/item_collection.rb:28:in `each'
    (ruby) enumerable.rb:225:in `to_a'
  • Repro snippet:
  collection = MyModel.build_query
    .on_index(:class_gsi)
    .key_expr(':tenant_and_class = ?', 'tenant-1#MY_MODEL')
    .complete!

  collection.to_a # randomly raises or returns nil

If aws-record embraced ActiveModel::Attributes (per issue #152), the enumerable bug would be a lot less painful to work around because:

  • Every attribute read/write would flow through Rails’ attribute stack, so you could normalize/
    sanitize values before they touch Dynamo’s marshalers—no need for custom “safe_to_a” guards
    sprinkled across the codebase.
  • You’d get ActiveModel’s dirty tracking and coercion for free, which means your
    Aws::Record::ItemCollection could just emit proper ActiveModel instances; they’d behave
    identically to ActiveRecord rows when enumerated, making it easier for the SDK team to reuse
    proven enumerable implementations.
  • Upstream fixes to ActiveModel types (e.g., handling nil serialization, type-casting edge cases)
    would land automatically, shrinking the surface area where the Dynamo-specific enumerable can go
    off the rails.

So, implementing the AMS attribute layer first would not only unlock normalization, it would also
simplify the SDK internals enough that bugs like the broken enumerable become much easier (maybe
even unnecessary) to patch.

Acknowledgements
  • I may be able to implement this feature request
  • This feature might incur a breaking change
aws-sdk-ruby-record version used

Ruby 3.4.4, aws-record 2.14.0, aws-sdk-dynamodb 1.176.x.

Lingua principale
Ruby
Stelle
318
Fork
44
Merge medio
3g 15h
PR unite (30g)
4

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di aws/aws-record-ruby

Tutte le issue di aws/aws-record-ruby

Issue simili

Altre issue su Ruby

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.