Skip to content

feat: SDS improvements #2541

@weboko

Description

@weboko

Description

During internal testing and wrapper development, several issues and inconsistencies were identified that reduce clarity, maintainability, and correctness of the implementation:

  • Naming inconsistencies in events, methods, and variables caused confusion, especially when terms from the spec (e.g., “delivered”) could be misinterpreted.
  • Verb choices in methods like sendMessage/receiveMessage were misleading, as they did not reflect the actual behavior (messages are queued for SDS rather than directly sent/received).
  • The Message structure lacked convenient methods for encoding/decoding, complicating usage.
  • acknowledgements terminology diverged from spec language (“possible” vs “partial”), creating semantic mismatches.
  • Event emission logic sometimes triggered events even when the underlying action did not occur.
  • Duplicate messages in history caused acknowledgment handling problems.
  • Testing coverage and logging were insufficient for debugging and validation.

Proposed Solution / Feature Design

To increase wrapper maturity and align it more closely with the spec, the following improvements have been implemented or initiated:

  1. Spec alignment – Added senderId per new spec PR #170.
  2. Better data model – Converted Message to a class to provide built-in encode/decode methods for easier handling.
  3. Clearer event naming – Adjusted event names to clearly indicate whether they relate to incoming or outgoing messages, avoiding spec term ambiguity.
  4. Accurate method naming – Replaced misleading verbs (sendMessage, receiveMessage) with terminology that reflects actual SDS behavior.
  5. Consistent terminology – Updated acknowledgements naming to match spec’s “possible” acknowledgment concept.
  6. Improved logging and tests – Added/fixed tests and introduced logs for better traceability.
  7. Event emission correctness – Ensured events are only emitted when the related action truly occurred (e.g., “delivered” only when delivery happens).
  8. Duplicate message mitigation – Began removing history duplication to prevent acknowledgment issues (full fix planned in a separate PR).

Metadata

Metadata

Assignees

Labels

No labels
No labels

Projects

Status

Done

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions