Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#153 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
aws, ruby
Lĩnh vực
databases

Hướng nghiên cứu

Bắt đầu với aws-record-2.14.0/lib/aws-record/record/item_collection.rb, đặc biệt là each ở dòng 28, và tái hiện lỗi bằng Model.build_query.complete! rồi đến to_a hoặc each. Theo dõi cách collection nhận Aws::PageableResponse của nó và kiểm tra đường dẫn each_page nil được báo cáo. Hoàn tất khi các truy vấn DynamoDB thành công luôn có thể được liệt kê mà không có kết quả nil hoặc exception.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Ruby
Star
318
Fork
44
Merge trung bình
3 ngày 15 giờ
Pull request đã merge (30 ngày)
4

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của aws/aws-record-ruby

Tất cả issue của aws/aws-record-ruby

Issue tương tự

Thêm issue về Ruby

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.