[BUG] Aws::Record::ItemCollection intermittently returns nil/raises from to_a and each #153
Description
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.