mikel / mikel/mail

Mail::Message#to does not always return the same type of object

Open
#997 0 comments 5 reactions 0 assignees View on GitHub
Header Fields More Work Needed Parser
Dominant language
Ruby
Stars
3.7k
Forks
934
PR merge metrics
No merged PRs in 30d

Description

Ultimately `Mail::Message#to` delegates to [calling #default](https://github.com/mikel/mail/blob/ada8aac12e8bf46af8cf4c90d41e669fb59d6f56/lib/mail/message.rb#L1197) on the field object of the To: header.

If the To header's field is a `Mail::ToField`, `Mail::Message#to` returns a `Mail::AddressList` due to the way default is [defined in `Mail::CommonAddress`](https://github.com/mikel/mail/blob/ada8aac12e8bf46af8cf4c90d41e669fb59d6f56/lib/mail/fields/common/common_address.rb#L80)

However, if for some reason the To field encountered an error in parsing the hear's field is now an `Mail::UnstructuredField` which returns a string of the decoded value when [calling default](https://github.com/mikel/mail/blob/ada8aac12e8bf46af8cf4c90d41e669fb59d6f56/lib/mail/fields/unstructured_field.rb#L59)

I run into issues when I assume `Mail::Message#to` is going to return an enumerable `Mail::AddressList`, but instead get a string. Any thoughts on what we might be able to change to make this behaviour more expected?

I understand the simplicity of having a `default` method on each field and why the header's field is an Unstructured field when the content is not parseable.

Would it make sense to add extra logic in `Mail::Message#to` to check the return value of `#default` and wrap it in a enumerable or something if it is not an AddressList? Or any other suggestions?

Thanks

Contributor guide

Open the contributing guide

Research direction

Start with lib/mail/message.rb around the To-header delegation, then read lib/mail/fields/common/common_address.rb and lib/mail/fields/unstructured_field.rb at the referenced default methods. Clarify the intended return contract for Mail::Message#to and add focused regression coverage for parsed and unparseable To fields; done means the behavior is consistent and documented by tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
ruby
Domain
backend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.