Refactor Delivery & Submission History Parsing & Validation

[thetaurean]

User Story

As a consumer of the API I want similar or paired API endpoints to behave consistently so that their outcomes are consistent and predictable.

As a developer I want to ensure separation of concerns and implement similar return behaviors in abstract function implementations so that their use is consistent and predictable.

Description/Use Case

The delivery and submission history APIs are inconsistent in their handling of a sender / receiver name. One requires a fully qualified name (e.g. some_sender.default) or an error is returned. The other does not and will automatically append .default when trying to locate a matching receiver.

Risks/Impacts/Considerations

• This likely touches code that is used throughout the project so consideration of all those uses is required

Dev Notes

• The underlying code (findReceiver and findSender) conflates validation with lookup and likewise in the caller.
• The two functions above have 87 hits in the codebase so definitely a risky thing to touch
• There was a previous ticket (#8332) that worked on making the endpoints behave more similarly, but the underlying code mentioned above was left untouched.

Acceptance Criteria

• Validation and lookup are separated and behave similarly for sender and receiver names OR
• Reasons for conflation or asymmetric behavior are documented

[avnieldravid]

@thetaurean any chance you can fill this out? not sure what this is for.

[bishoyayoub]

@thetaurean Please update when you can.

[bishoyayoub]

@thetaurean Would you able to please see if this is still required? If so, please apply the new template.

[thetaurean]

Updated to new template.

[bishoyayoub]

Hey team! Please add your planning poker estimate with Zenhub @arnejduranovic @jack-h-wang @JessicaWNava @jimmyfagan @luis-pabon-tf @mkalish @thetaurean

[bishoyayoub]

Please add your planning poker estimate with Zenhub @JFU-NAVA-PBC